Book recommendation: “Creating great teams” by Mamoli and Mole

Here is a new, interesting, informative and easy to read book on forming teams. “Creating Great Teams: how self selection lets people excel” by Sandy Mamoli and David Mole takes the reader step by step through the process of building teams by enabling them to self-select.

This book is based on the “belief that people are at their happiest and most productive if they can choose what they work on and who they work with” – an appealing theory, but does it work in practice? The authors do not just present a theoretical construct, they describe a case study of an organisation where they were successful in implementing the self-selected teams method, and they discuss their fears, problems and blockers honestly, showing how they overcame obstacles. The refer to other organisations that have used the method, and provide qualitative and quantitative evidence in terms of anecdotes, results of staff surveys and company results.

The book is divided into short chapters, starting with an explanation of the ideas, then step by step through planning and preparing for self selection, the self-selection workshop, and importantly, the followup required to implement, launch and support the new teams. Each chapter provides checklists, guidelines, hints and tips, and practical experiences.

So – what is self-selection? When teams self select, instead of managers assigning people to teams, the teams choose themselves. Given the projects that are required, the people within the organisation choose which project they want to work on.

I was lucky enough to meet Sandy at Agile India 2017, and when she described the method to me I was excited by the concept, but at first sceptical. I could see problems: what if there were project no-one wanted to do? What if everyone wanted to work on the same project? What if there were people no-one wanted in their team – wouldn’t it all be a bit like sports lessons at school (where I was always chosen last…)? Sandy & David show in this book that they faced the same doubts, and they show how to overcome them. Happily, rational, intelligent adults react well to responsibility and choice.

In this review, I will not go into detail about the methods they use and the checklists they provide. I urge you to buy the book! It is really good value and will make you think anew about how you build teams.

ISBN 978 1 68050 128 5

https://pragprog.com/book/mmteams/creating-great-teams

Get it, read it, think about it, notice the effectiveness of the working method.

Building and Testing the Tool Builders’ Workbox

In my last blog, I presented a vision of a better UX for those who use tools – a Workbox for the tool builders. How can I design, build and implement the tool builders’ Workbox? Not by myself; I need a team of people around me with different skills and knowledge, that complement my own knowledge and skills.

So far, I have identified the tasks that are needed as:

  • Research and Development (R&D) to isolate and understand out the specific problems with the current tools for the people who use them. Methods might include:
    • Interviews with people on software development teams, but also …
    • Interviews / questionnaires with people entering the industry;
    • Interviews / questionnaires with people leaving the industry, or choosing not to enter the industry when they have the capacity to do that;
    • Analysis of other research on whether the choices people make are affected by gender, culture, or other factors, based on existing research from others;
    • Data analytics;
    • Usability testing of tools;
    • Heuristic evaluations of tools;
    • AI/semantic analysis.
  • Prototyping of a new Tools User eXperience
  • Composing and trialling guidelines and templates for tools builders
  • Building and delivering education and training courses, via for example webinars
  • Awareness building through the industry via conferences (I am going to be speaking on this topic at UCAAT in Budapest in October and also will be at the Google Test Automation Conference (GTAC) this year, with a chance to discuss the ideas);
  • Trialling the prototype Workbox with tools builders.

In the first instance, it makes sense to talk with the tools builders in the open source world but I also want to converse with commercial vendors about this. It makes sense to me to start with test tools, in particular test automation, because I work in testing & quality and so know people with expertise in that area of the industry. I have called this part of the Workbox: TUXT (Tester User eXperience of Tools).

It could be wonderful. It will be wonderful.

 

 

A vision for the future: a workbox for tool builders

Software is ubiquitous, and yet so often fails to delight us.

I work in the IT industry, principally in software quality improvement, user experience and software testing. I have over 30 years of experience. I observe a problem with software: it is ubiquitous, yet fails to delight us. I observe a problem with software engineering: the tools used by engineers is hard to use. This leads to poor decision making and hence to delivery of inadequate software that delivers an inadequate user eXperience (UX).

The problem

The last few decades of experience highlight for me a conundrum: technology changes rapidly, yet the mistakes made when delivering software are repeated as each new generation enters the industry. In my last two blogs, I discussed Why everyone needs a better experience of software and Why we need a better tool set for building software. I said that technology and software are flawed. I said that the industry and its tools reflect an unconscious bias, towards a notion of a “typical software engineer” which then becomes self fulfilling.

Supposing we could change that?

The vision

My vision is to radically improve the quality of software, specifically the user experience (UX), by addressing one root cause of the problem: the engineers’ tool set.

  • The tools used by the teams who design, build and support software are essential, and could be a delight to use – if designed with UX in mind.
  • The tools could provide a beautiful UX to a wider group of people so that a diversity of people are encouraged into the industry
  • The tools are then made by “diverse software engineers” and used by “diverse software engineers”
  • The tools reinforce the use of interface designs that appeal to “everyone” because they are naturally and usefully beautiful.

If the tools are improved and modernised, then it will easier for engineers to deliver software that delivers a beautiful UX, because they themselves will experience a beautiful UX. Also, a wider range of people will want to be engineers and use the tool set.

By engineers I mean anyone working on the delivery; some may not see themselves as engineers. They may be product owners, business representatives, acceptance testers, even sales and marketing teams may contribute. In terms of job roles within the team, they may be designers, developers, testers, release teams, support teams.

All of those people contribute to the users’ experience of the software. All of those people rely on tools to provide information about the software and how it behaves. All of those people will contribute information – often into a tool – which feeds decision making about the software. Few of those people build their own tools. Many feel undervalued, unsung, and, as we saw in my earlier blog, blocked/dehumanised by the tools they use.

The workbox

My plan is to implement a project that will to help tools builders improve their tools. This will enable the engineering teams to concentrate on making software delightful, improving the UX for everyone. I want to provide a Workbox for the tool builders, that contains everything they need to build beautiful tools for the software engineers. A workbox is more than just tools:

  • a sewing workbox is used to hold everything a sewer needs: tools, materials, equipment, notions, patterns, machinery, supplies.
  • a professional’s mental workbox has tools, materials, equipment, notions, patterns, machinery, supplies, plus an attitude of mind and approaches that are versatile, flexible, strong, multipurpose, and cost effective.

As we saw in my last blog, the current tools do not help the teams provide delightful software. They are old and require the engineers to think about the tools rather than what they are making. Usually, engineers do not build their own tools, so providing tool builders with a Workbox of tools, patterns, and methods that improves UX for the engineers will enable them to deliver better solutions for their customers.

The Workbox

The Workbox for tool builders will include:

  • Tools for checking the UX of the software engineers’ tool set
  • Methods for designing, reviewing and testing the UX of the software engineers tool set
  • Notions, training materials and guidelines that explain the why and how of UX.

The UX will not just be focused on what is right for a “typical software engineer” but will also give guidance for the UX required for non-technical people using the tools. These can include managers, business representations, acceptance testers, people who are contributing to the IT project but in a non-development engineer capacity. They too need to use and understand the tools. In my next blog, I will start to form a plan for building the Workbox.

It could be wonderful. It will be wonderful.

Why we need a better tool set for building software

At the end of my last blog, I asked, “So – why is technology flawed? Why not build it well in the first place?” There could be several reasons, today I want to discuss just two of many:

  • Limited types of people in the industry: The software engineers do not always understand what is needed because they may not understand the people who will use the technology. Because of this they may deliver software that is the product they themselves want to use. This means technology can be biased towards the type of people who are already software engineers.
  • Automation bias and poor decision making: The software engineers and the non-engineers on the project team may have a toolset that does not enable them to make good decisions. Yes, all the flaws in technology that I talked about in the previous blog are also true for the tool set that software engineers use. The tools are intended to help decision making in the project. Is the software ready? Has it been tested? Does it work? Are there any risks in delivering it now? But if the tools are flawed, and hard to use, people are more likely to make poor decisions with poor outcomes. That will lead to flawed software and potentially an ugly UX for everyone else. Note that technologists and software engineers also suffer from software with flaws in it, software that is hard to understand, and tools that prompt them into automation bias.

Two sayings that come to mind here “a fool with a tool is still a fool” and “a poor workman blames his tools” and it would be easy to stop at that. But the industry has spent too long building up some traditions around old mind sets and old tool sets that favour old ways of doing things. If technology and software is to serve and reflect the widest population, to everyone’s benefit, then the teams need to reflect society. If the teams reflect society, then the tool set needs to be easily used by a wider range of people, not just the obvious technologists.

As Seth Godin remarks in [Demand Guardrails] “If peer pressure and short-term urgencies set us up to do things we regret, we come out ahead when we support cultural changes that remove that peer pressure and lessen those short-term urgencies.” This blog is a call for a change to the tool sets used by software engineers, to make them easier to use, easier to understand, and supportive of good decision making that tends to a beautiful UX for everyone. We need to support cultural changes in the world of software engineering that remove the peer pressure of being the same as we’ve always been. We need to support cultural changes that remove short term urgencies that stop us mending out tool set. We are the cobblers, and we are the cobblers’ children with no shoes.

Old tools sets are hard to use. Early sewing machines required skills with the machines that are not needed by modern machines; a sewer today can concentrate much more on the project, and less on the tools. Early cars were hard to drive, with starting handles and double de-clutching to master. Modern cars are easy to start, easy to drive, automatic gears and power steering. The driver can concentrate on the journey and the destination. More people can use a sewing machine now, and make their own clothes. More people can drive, and have the independence to make journeys. [Rise of the female petrolhead, Car electric starter, Treadle sewing machine difficulty]

I would like to move software engineering tool sets to beyond the treadle machine and the car with a crank handle starter to a modern, smooth system where automation and tools serve the project team rather than being a hindrance. This will address both the problems above:

it is like working with something designed to be used by a 12-year-old boy in his bedroom in the 1980’s”.

“Why would I want to use a tool called Github?

But this is not just a problem about gender or culture; the tools are themselves flawed and old-fashioned.

  • Tool flaws: IT teams are themselves beset with the same problems and frustrations with the tool set they have to use, and this leads to the release of highly flawed software. Many IT tool sets are almost deliberately arcane and are gender biased. Many become “shelfware” – purchased but hardly ever used. Others are used with automation bias – the results are wrong but are treated as correct. Here are some more quotes from developers, testers, and researchers about flaws in tools

Developer: “I spend 50% of my time wrestling with the technology instead of solving the problem I am working on” Quote from WII meeting

Software tester finding decision making not supported by IT toolset: “The test tool marked all the tests as passed except 1, but in fact none of the tests marked “passed” had actually run” Quote from Fewster and Graham “Experiences of Test Automation”

Problems with customer support tools: “Ethnographic research paints a sad picture of the current state of the ITSM market.   …vision is to build a solution designed for humans, not processes” [http://blogs.ca.com/2016/01/27/moving-itservice-management-to-the-21st-century/]

Evidence that developers do not find tools easy to use: “…so now I wanna know why raising a string exception is bad. Like what should I be doing instead? Since it thinks it’s a problem. And so none of these really help me…” (Why Don’t Software Developers Use Static Analysis Tools to Find Bugs? By Johnson, Song, and Murphy-Hill).

Evidence that tools do not work for IT people “…a lack of consideration for how people work and think … basically it’s still the mindset that the human adapts to the computer, not vice-versa.” (A Taxonomy of Tool-Related Issues Affecting the Adoption of Model-Driven Engineering by Whittle, Hutchinson, Rouncefield, Burden and Heldal)

In the previous blog I said: The reasons that technology and software may prompt poor decision making include defects in the software […or that it…] may function correctly, but in a way that does not aid people in making good decisions. … dealing with frustrations, defects and consequences of poor engineering is a bad experience for the people using the technology; a flawed, ugly UX. That is true for tools used by the teams delivering software, and is a key root cause for the problems we all experience with delivered software.

What I will propose in my next blog is a solution to these problems.

Why everyone needs a better experience of software

If someone makes the wrong decision what might be the impact? It could be frustrating, or dangerous, or even fatal. We all make decisions all the time – what to eat, what to wear, what to read or watch. And frequently we make very important decisions – financial decisions, life changing decisions. We also rely on experts and professionals (nurses, doctors, pilots, financiers, politicians) to make decisions for us.

Apart from our own knowledge and brains, the tools we have to help us are technology, and software. Technology is cheap, and has become the basis for much of people’s decision making.

Software as part of that technology is now ubiquitous, but often fails to delight us. It fails to support good decision making. When the technology goes wrong, when the software is flawed, what is the impact? For example, a satnav that is out of date may give us directions that take us into a road that is no longer driveable. As humans we then need to engage our own brains and override the suggestions of the satnav. But often when automated decision making is provided, people will over-rely on it and fail to over-ride flawed decisions – the [automation bias].

This is important because of the breadth and scope of the decision making that technology supports. Many people are using a wide range of different systems to make many types of decisions:

  • The impact of our decisions may be personal (shopping, dating, entertainment, directions for travel) and important to us, an individual.
  • The impact may be organisational (financial forecasting, data analytics for marketing) where the outcome of the decisions is important to a board and shareholders.
  • It may be geographical, political and global (weather forecasting, border controls, international policing) and important to citizens of many countries.
  • One country’s politicians may use decision making systems local to one country (medical/health population trends, voting systems) and the impact will be on the politicians and the general public.
  • The people using technology may be experts / professionals (doctors, nurses, pilots, farmers) or lay people (patients, travellers, shoppers).

The reasons that technology and software may prompt poor decision making include defects in the software that mean it does not function correctly. If we are lucky, the defect will be sufficiently bad that it is obvious the output is wrong, and so people will correct the software, or ignore/override it. Sometimes, the software is wrong, but it is difficult to see that it is wrong. In that case, people are misled into trusting it, and so may make poor decisions based on flawed advice. More subtly, the software may function correctly, but in a way that does not aid people in making good decisions. The software may be slow, insecure, hard to use. The “user experience” (UX) that a person has when using technology and software should be beautiful, that is what is intended. But dealing with frustrations, defects and consequences of poor engineering is a bad experience for the people using the technology; a flawed, ugly UX.

So – why is technology flawed? Why not build it well in the first place? I will discuss  a couple of the reasons for that in my next blog.

Quilting and hacking

Two blogs to which I subscribe had new posts this week, and they just fitted together:

Now I know sometimes I can be a little obsessive about the analogy between sewing and IT; the need for a workbox, the need for new ways of using old methods, the way the projects are similar… but I urge you to read them both and compare.

A project works when you understand the materials you are working with, how they fit together, and how you can modify them. Repurposing happens with fabric and with code. Hacking can be a good thing – with code and with fabric. But you need to understand the pillars for success. The Googletesting blog suggests to me:

  • refactoring old code so you can reuse it
  • consistent formatting giving patterns that you can follow and
  • use of structure and architecture to hold everything together

Knitnkwilt suggests to me

  • working with what you have got by reusing/repurposing old things
  • using a consistent pattern framework to hold the design together and
  • enhancing the old with new structure/fabric.

 

 

 

Quality in Use tutorial: SEETEST Bucharest

Quality in use is a really important concept for IT teams to understand. We get very focused on building, testing and delivering functionality. We also put some emphasis on what testers call “non functional testing” in other words testing quality attributes other than functionality. In particular, performance and security testing are a focus for many teams. However, customers choosing a product will be looking at whether it is usable, flexible and safe – they assume it’ll work functionally. They will also be drawn to products that provide the right experiences – we use words like excitement, flow and trust to describe how someone experiences a product or service. Attributes like functionality, security and performance are important because they are the foundations that underpin great quality in use, and a beautiful user experience.

I’m really happy to be going to Bucharest in September for SEETEST, where I will present a half day tutorial on Quality in Use and the user experience. It’s my first time in Romania, so I’m taking a few extra days to look around Bucharest. Looking forward to that, and to the conference. The tutorial summary is below.

Quality in use

… the beating heart of the user experience

Public presentation

  • Half day tutorial for SEETEST 15 September 2016
  • Also available as an in-house 1 day tutorial on request

Audience

The class is principally aimed at practicing testers and test managers who want to improve the alignment of their testing to the business and user needs.  This includes people in roles such as system testers, test analysts, test engineers, test consultants, test managers, user acceptance testers and software developers. No prior knowledge is assumed and attendees do NOT need a PC for this course.

Concepts

As testers, should we focus on details or on the big picture? Our skill set and comfort zone is often in the detail; we find excitingly obscure bugs and report these problems in detail. But does our zeal sometimes cause us to miss the big picture of what the customer and the business really needs? Do we focus on software defects at the expense of human and commercial factors? In today’s business environment, the user experience and the commercial imperatives have become overwhelmingly important. As testers it is vital that we understand quality in use and the user experience, in order that we focus our tests correctly.

“Quality in use” measures products and services looking at human, business and societal impacts; this includes usability, accessibility, and flexibility for the customer and business, as well as commercial, human and environmental safety. These are underpinned by technical and engineering attributes of a product, and build together into a “User Experience”. For the people selling, supporting or using the products, this is the beating heart of the customer experience. How well are people supported to effectively and efficiently carry out their tasks? Is the product accessible to all the people who want to use it? Does the experience of using the product generate human reactions of trust, excitement or other reactions that will encourage users to continue using and to recommend the product? Do we reach the customers’ hearts as well as their purses?

Without these “big picture” attributes, delivered software will not be acceptable, will not keep our organizations in profit, and may not be legal. The benefits of designing in and testing these attributes will make the users more effective, more efficient, and increase the marketplace for our products and services.

In the tutorial, Isabel will use examples from ISO25000/ISO25022 and from real projects to discuss how testers design tests derived from the user personas, contexts of use, and acceptance criteria.  This requires testing during early testing of concepts and designs and later testing on built products.

Standard ISO25000/ISO25022 defines a group of attributes and metrics that build from the internal engineering qualities and attributes, such as the functional attributes, performance measures and security, to the Quality in Use attributes of usability, context coverage and freedom from risk, with the user experience attributes such as trust, excitement and flow are at the top of the pyramid. Trust, excitement and flow in a task all affect the human heartbeat – user experience is the beating heart of the user experience.

Participants will learn:

  • To distinguish the layers of quality that must be designed and built into products, and tested;
  • How to understand and meet the context of use for each customer persona, from the internal quality through quality in use, to the user experience;
  • How to focus testing on customers, end users and the business;
  • How to select attributes from each layer of the user experience pyramid to track and measure during testing;
  • How to agree acceptance criteria for testing internal quality, quality in use and the user experience.