I’ve been fortunate enough to be selected for some great training this month in LEAN and Warwick Uni’s flavour of it, SCD.
However a couple of the sessions really highlighted the difference between “working on your own first” or “starting in a group”.
When you’re sent off to do a group task on something new, you haven’t had to process the flow, the steps and the outcomes. Then trying to work it out together becomes a mix of people not really able to work together.
But when you give your attendees, time to work and process on their own before hitting the group, often the results are better as we’ve all processed on our own time how things work.
The 1st group event on a Training day is better preceded by some “own time”
Meetings rarely offer individuals time to focus and think. Group brainstorms—where everyone shouts out ideas and builds off one another—can be fun, but in my experience, the strongest ideas always come from individuals.
We all like a good personality quiz, c’mon you’ve been tempted by a few Quizzes on your Facebook profile and Buzzfeed right? You hope they may reveal some insight and reflect some personal characteristics back at you whilst making you accept you may be more Hufflepuff than Gryffindor.
Well the Strengths Finder 2.0 by Gallup is a professional version of horoscopes / Buzzfeed questionaries for your working life. It offers you insight into your strengths, personality traits and supplies action plans.
The main drive for this “Strengths only approach” is the theory that your Effort multiplied by your Strengths will give you bigger gains than working tirelessly on your weaknesses for minimal gain.
Strengths X Effort = Maximum results
So ignore the weaknesses, multiply your talent and boss it.
I’ve done DISC profiles before with Inge, and I’ve had nearly a similar benefit from this. You get reaffirmation of your values back to you, but with this, it comes with dropping the baggage of your weaknesses and only aiming to take action on your Strengths.
Very pleased to share with you a recent win both of my team’s pitches have achieved in the Santander Digital Innovation Challenge.
Warwick Uni is putting some money where it’s mouth is and is sponsoring early stage ideas across the University to improve everyone’s working lives.
Both teams I put forward have won a cash prizes, and in February will be starting some early validation of ideas.
What are the ideas? Can’t say too much yet, but one is to disrupt an internal space rather than wait a large organisation to supply us with something (we will be doing validated learning to improve), the other is attempting to leverage some new tech to channel shift a team’s work load.
I’ve already said to much! But I’m glad we won so had to share something, more news in Feb 2017.
It talks of reducing waste and validating assumptions. It talks of validated learning and not just saying, “we’ve all learnt a lesson” and moving on to make the same mistakes again. It talks about making experiments part of the fabric of your work and making things which fail but validate assumptions on your vision and helps you move along.
By doing experiments, like split tests on your site or bootstrapping business ideas, you learn about your visions cheaply, and reduce waste.
It’s so like Agile development, but for your business ideas.
Our in-house development projects are well covered for Unit and Frontend tests since we adopted BDD (behat) and a bit of TDD (phpspec).
However, creating lots of tests has an impact downstream on our shared Gitlab CI server. Every-time we push a new set of changes to GitLab the tests are taking 30mins to complete and beginning to slow us down.
So here are our 3 easy tips to speed up your test runner and reduce the time it takes to run a full test run.
Increase the Gitlab Runner’s Concurrent setting so we’re using the server’s resources to it’s maximum, `concurrent = 50`
Split up the most time consuming test suites into small suites so we keep most suites under 2mins. We’ve gone from test suites, to calling individual Unit test Classes for the slowest tests.
Prioritise the longest jobs first (put them to the top of the gitlab-ci.yml) so they can get going immediately and not hold anything else up
If you’re lucky enough to have access to the Virtual Server, then increase your CPU’s. That shaved 2 mins off our test
These simple and inexpensive changes have taken us from 30mins to 5mins 30s.
Recently I’ve been looking to improve our app delivery QA. We’ve had to come up with a solution for our team to run the QA.
So we got the test plan from them and currently the QA was being run from a spreadsheet… on one person’s machine.
So after much chatting with our WMG Team, I lead the design and implementation of QA system we’d be more used to. This also meant rather than me diving is a developer and just writing some tests, I am utilising the resources available to me.
Our new system…
Keeps our workflow in Trello, which means shared work and understanding
Handles file uploads and pictures for visual help with Asserting something passes
Can push failed tickets straight into our Sprint board for resolution
Can write verbose test instructions so the QA can be passed to anyone in the team
Handles discussion on why it failed, or mistakes
We can copy the board for each build
In the “Master board”, we write new QA tests and maintain the Master instructions
When a new build is released, we duplicate the “Master board”, we add the build number to its title to make a “Build board”
We share and assign the QA tickets to the team
We process them in order
Any passes, we just archive the ticket, gently clearing out the board
We mark any errors / fails / bugs in the “Build board” and move them to the Sprint board, “Failed QA” column