We’re ignoring our stakeholders and they couldn’t be happier!

The following is a set of techniques that at WMG, Warwick University I have led and implemented on various digital projects to great success. Stakeholders are happy with it, and they’re not inadvertently altering the success chance of the projects.

You’ll recognise this. Every project you run, has a plethora of stakeholders involved. In some large organisations too, you’ll find they enjoy a rather flat structure where everyone’s opinion is valid and should be considered.

So when you invite lots of people to a meeting, you come out with a mess of features and a confusing array of project actions which possibly didn’t need chasing up. Because of this we need a framework that will allow for ideas from all people, but only qualify the ones which are “goers”.

Here’s 4 tips that I use with my teams at WMG to both keep the stakeholders happy. It makes but the project the most important success factor, not egos. It makes everyone nearly equal.

1. Have a shared Product Backlog or the “the duff idea buffer”

Headline.
This is a place where all ideas are held and are accessible to every stakeholder. This isn’t an obtuse Word Document you keep emailing round with “Track changes on” and forgetting to CC (Carbon Copy) people in, but more like a shared pinboard on Trello.com which you can export every so often to Excel.

Reasoning.
The reason for having a shared Product Backlog is more to do with human behaviour than anything else. Often in a working group of many, you’ll find most of the angst is whether or not someone’s personal idea was set down and recorded. Some / most of the suggestions will be pants, off-topic and not worth the keystrokes you took to record it, that’s natural, we all do it.

However, if it’s fairly recorded somewhere you can move on, rather than discussing its use-fullness there and then.

Often you’ll find that the person who raised it, after a couple of days, gets some perspective and realises they don’t think the idea’s any good anymore.

1. Have a Product Owner (the gatekeeper)

Headline.
This is 1 person. Not two, three or 12. Just 1. It is 1 person who was voted by the stakeholders as the “best decision maker for the project” and who always decides what’s the most important action for the project next.

Reasoning.
So sure, the stakeholders have now had their thoughts recorded into the backlog, but let’s be honest, quite a lot of that might not be immediately urgent or produce the highest business value. So a Product Owner is voted in by the stakeholders as the person best placed for making decisions on the product.

They have authority. They were voted in by their peers, and so can yay or ney actions confidently. Also, if you’re worried about someone being voted in that’s a bit power hungry, it’s good to know that this role has a lot of responsibility, so their decisions have to be good, they’re picking how the project progresses.

3. Be strict.

Yup. They’ll hate this bit, but you need to vote in someone who can stick to these rules and keep to the rhetoric of, “Great idea, put it in the Backlog”, “You don’t get to pick, it’s the Product Owner’s choice”.

This way, no stakeholders can adjust how the project goes as they agree to the rules of the Product Owner says what’s next. By staying strict it helps fight the “culture eats process for breakfast” saying and starts adjusting how you work together.

4. Keep everyone updated, frequently

Every 2 weeks, re-present to the stakeholders what’s done so far. Then chat about what they think is important next. Invite them all every time, and after a while you’ll see they more just want to leave you to your work and don’t turn up. Allowing the process to move on.

The Product Owner can then make the decisions based on feedback about what’s next.

I hope that helps!

Note…. In the title, I mean, “happier” with our process, I imagine their first child or standing on a surfboard might also be a happy event.

 

Changing the storage path in Laravel 5

So changing the Storage path in Laravel 5 is apparently more difficult than it possibly should be.

Here’s how I solved it with @stauffermatt ‘s tutorial to start but appended to make sure the storage path is stored in Config per. server rather than hardcoded into your Git stored php files.

  1. First follow Matt Stauffer’s tutorial, and add an application override

https://mattstauffer.co/blog/extending-laravels-application

# File /app/Application
<!--?php namespace App;

class Application extends Illuminate/Foundation/Application
{
    /**
     * Get the path to the storage directory.
     *
     * @return string
     */
    public function storagePath()
    {
        return $this->basePath.'/theNewStorage';
    }
}

  1. Then change your `bootstrap/app.php to…
$app = new AppApplication(
realpath(__DIR__.'/../')
);
  1. NOW, my extra bit. Create a config/paths.example.php and add it to git. Then duplicate it as, config/paths.php, add that file to your .gitignore and change the path to the server’s storage path.
<!--?php 

return [

    // Url to the server's storage file
        // eg, 'storagePath' => "/var/www/storage",
       'storagePath' => base_path()."/storage",
];

  1. Alter you app/Application.php file to load in the Config Repo with your new config file
<!--?php namespace App;

use Illuminate/Config/Repository as Config;

class Application extends Illuminate/Foundation/Application
{
    /**
     * Get the path to the storage directory.
     *
     * @return string
     */
    public function storagePath()
    {
        $path = config_path(). '/paths.php';
        $items = include $path;

        $config = new Config($items);

        return $config->get('storagePath');
     }
}

There. Dunnit.

SQLite and multiple renaming or dropColumn ‘s error in laravel 5.0 aritsan migrate

So #HTH

One of my migration scripts in Laravel 5 has 3 dropColumn requests in and 1 rename column. This all works fine with laravel migrations on MySQL and MariaDB, as you would expect.

However once you try to run those same migrations on a mysqlite / sqlite database you may start seeing errors like so

SQLSTATE[HY000]: General error: 1 no such column: XXX (SQL: CREATE TEMPORARY TABLE

Now following up the issue on Github it is related to this, https://github.com/laravel/framework/issues/2979 but Taylor doesn’t believe it’s a bug, saying,

I would do them in two separate operations.

 The work around unfortunately is to split EACH drop Column and rename into 1 separate migration file each…

Crazy, but tbh. if that’s the worst bug I come across with Laravel 5, I’ll take it.

Disable the CSRF token in Laravel 5

Just a #HTH

Often when you’re devving’ forms in Laravel a quick refresh of the page rightly errors on the CSRF token. This is a bit of a bummer if you want to keep testing the same request, so all I do is…

Goto App/Http/Kernel.php and comment out,

// 'AppHttpMiddlewareVerifyCsrfToken',

Then you can dev to your heart’s content, just remember to un-comment it! Maybe write a unit test to check it’s on before allowing you to push or create a merge request. Like one that alters the hidden field and submits.