Categories
development leadership quickfix ux wtf

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Categories
leadership

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products ContinuouslySense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

Categories
development

Bad change : re-opened tickets and the neverending change

IMAG0085
It goes on and on and on

One reason I don’t trust change is when that change has no defined end goal. When a change is requested, and the ticket completed, but it then enters a cycle of scope-creep that means the ticket can never be closed.

They often start with something simple e.g. “can you improve the performance of this search”, with a simple tweak – add a JOIN clause to avoid SELECT 1+n queries. In some cases the user acknowledges the improvement, but some users will start pushing new features against the request “because it’s in the same area”. After all, changing the colour of the links on the search page is still part of the same use case, right? And the fact the search is still slow when I use this rare combination of fields means the original ticket wasn’t fixed.

Close it and move on

In some scenarios, it’s easy to be brutal. These are time-bounded sprints, so anything raised must be factored in. This works where features and bugs are interchangeable and represent simply “work to be done”, however they are charged, and let the retrospectives and other analysis worry about whether any particular piece of work is a bug or a feature, so that the team can ensure it’s delivering the best business value.

The definition of done needs to be clear from the ticket (although maybe not to the detail of a SMART objective, it’s worth thinking about that framework). If the provided steps no longer produce an incorrect result, or a speed improvement is recorded, or some other pre-defined success criteria is met, then the ticket is done. Any further discussion is a new ticket. If the objectives aren’t met, it should not be marked as done and the developer should continue work on it.

It’s under warranty

Many software products and projects have a grace period of warranty, where bugs are fixed for free. This is typically useful to resolve conflicts in untested combinations, or volumes, but it can also be used as a stick if the developers aren’t careful. Provided the warranty period is reasonable for the size, complexity and support arrangements within the project, bugs should be fixed to ensure the original scope is delivered. Some customers will however try to extend scope by issuing bug amendments to change scope, under the guise that the bug was raised during the warranty period is therefore should be resolved. After all, bugs should be fixed, but features must be paid for.

Make sure you have a good rapport with your client, and make sure the terms are clear.

Decide now what done means, and how to manage tickets

The last thing you need is to decide this when the tickets that’s blocking the release gets re-opened for the 100th time because the CSS is broken in IE6.

What does it mean to be done?

What constitutes a failure?

Can the software be released as it is?

Categories
development lifehacks

The tech diversity blind spot

 

wp-1450118461565.jpg

Technology makes the world better. It promises to make our lives better. It will free us from work.

Except “The best minds of my generation are thinking about how to make people click ads”. And tech lives in social bubbles as well as financial ones. Apps designed for silicon Valley don’t always travel to the rest of the USA, apps for Western countries don’t always apply in the East, Facebook and Google aren’t always trusted, VR headsets that don’t work if you wear make up, facial recognition fails if you don’t have the same skin as the webcam software developer, or the photo auto-categorising application developers.

Sometimes the solution is to write technology in another bubble. Brazil, India, China, and many other places have strong home grown technology far more popular than the “global” leaders. Sometimes you expand your bubble, diversified teams, balanced teams, who are smarter than homogeneous teams anyway.

Sometimes you look outside your bubble. I get paid to write software that I will likely never use. Line of business applications, including public interfaces, for government clients. I don’t know what their business is until I ask. I don’t know how they work, or what is important to them. And sometimes I have to ask several times, and sometimes people can never understand or articulate what they do, let alone what they want, even after asking them in several ways. So what makes you uniquely qualified to understand what you do, or what problems you have, or whether those problems are universal?

If you want to know if your intuition applies to the population as a whole, make sure your stakeholders reflect that population, or accept that you are deliberately limiting your audience, because that’s what makes sense to you.

Categories
development leadership

Bad change : the hokey cokey requirements

image
It goes on and on and on

When I said I don’t trust change, there were a number of situations I was specifically thinking about, changes that actively cost time and money and decrease business value. One example of this is what I call the hokey cokey requirements.

You can identify these where the business value of the requirement is unclear. Where the product owner is making decisions on behalf of a user without verifying them, or not considering the impact on other requirements, for example, how changing a date for one screen will cause a dashboard somewhere else to report additional failures.

If you’re lucky, you’ll identify the requirement before you start implementation, but more likely, it’ll be in until you release to test or even live, and you’ll immediately get a change request to take it out again.

If you’re really unlucky, you’ll then end up in a tug of war between 2 teams.

How can you identify them in advance?

For some systems, you’ll have a well defined dependency graph between requirements, or at least enough prep time to generate the dependencies from the code prior to accepting the requirement.

For others, you’ll need a big user group to cover the edge cases, and accept that big user groups are not a comfortable fit for agile development.

How do you deal with them when you find them?

Make sure the right users are involved, at design and test. And make sure there’s no hierarchy to invoke. What works best for the CEO might break the workflow for the administration team. On the projects I tend to work on, keeping the administration teams happy are the key to a successful delivery and simpler support.

Sometimes the smallest possible change is best. Don’t build the full solution, build just enough for all sets of users to see the implications.

Make sure you understand the impact, so you can explain it clearly.

But most of all, if you see it happening, try and build a ripcord into the code to pull it out again, like a feature toggle, because despite best efforts, you may still hear “I know that’s what I signed off, but I didn’t expect it to do that!”

How have you dealt with hokey cokey requirements?