Agile in an Hour

For some mysterious reason the Leads got ‘volunteered’ to run a Brown Bag session on Agile. This was to last no more than an hour and was advertised as:

This session will bring a dynamic IT trio together (G, J and P) to introduce the business to the Agile methodology and its applicability.

 As most of you are aware, Agile is the preferred method used by our Software Delivery Team to deliver software products. Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It works by breaking projects down into little bits of user functionality called user stories, prioritising them, and then continuously delivering them in short two week cycles called iterations.

 However, Agile approach can and has been used in our daily tasks as well and with some innovative twist, it can be applied to many different areas. G, J and P have prepared a little fun, interactive workshop for everyone interested, so bring your enthusiasm and creativity along!

(We also had N as we are in fact a dynamic IT quartet)

So we have a whole Hour to describe the Agile methodology and present it in a “Fun” and “Interactive” way…  Oh dear.

I Love it when a Plane comes Together

The team sat down and tried to work out how we could explain Agile in an Hour and throw some sort of interactive activity to hopefully illustrate some of the concepts in a “Fun” way.

We leapt on the Agile Airplane game (http://gistlabs.com/2011/06/agile-airplane-game/) as a potential candidate – but the running time for this was around two hours… Add in a bit of chat about where and what and how Agile works, a wrap up/questions bit and we estimated we had 30 minutes to actually run the activity.

Plane Paper

So out with the metaphorical scissors and we trimmed the game down to a couple of Sprints which would (we hoped) illustrate some of the key concepts of an Agile method including:

• Iterative Approach
• Self-Organising Teams
• Work Planning and Prioritisation
• Retrospectives
• Making Paper Aeroplanes

No Plane Survives Contact with the Enemy

So we had a plan – and when we saw the attendees list we were able to spot two  IT Team members were coming along (free food always attracts IT staff) and they were shanghaied into being guinea pigs (as in a rare moment of clarity we decided to test the modified game out first) and then Product Owners when we actually ran the Brown Bag activity.

Turns out it was a very good moment of clarity having a test run first. We discovered that there was no way we could produce the suggested 15 planes that would constitute a batch in the 4 minutes the work of each sprint was to take, and we needed to make sure that the teams would have enough time to demo and then discuss (retro) the next sprint.

The batch size was dropped to 4 Easy or 2 Hard to give Teams a fighting chance and we set out the Time Boxes like so:

Activity	Time
Sprint 1 Questions and Planning	2 Minutes
Sprint 1 Work	4 Minutes
Sprint 1 Demonstration	8 Minutes
Sprint 2 Retrospection and Planning	2 Minutes
Sprint 2 Work	4 Minutes
Sprint 2 Demonstration	8 Minutes

giving us a little wiggle room…

In addition we were able review what the rules of the game to flesh out what the “Product Owners” would be able to offer in the way of advice and support to the teams.

Time to Kick the Tyres and Light the Fires

G in Full Flight

G kicked off with a great (but rapid) introduction to Agile in general and Scrum in particular, setting out the principals and illustrating the various aspects of the  Scrum Framework.

We then launched into the activity – a short scene setting (we’re a startup looking to disrupt the paper plane building industry…) and the timer for for Sprint 1 was activated. The 4 teams (as we sort of expected) dived straight into paper plane production (we had kindly supplied 4 different designs – 2 easy and 2 hard) and before they knew it time was up (we had a $10 overtime fine for anyone caught working after the Sprint End). The Teams then demoed the flight characteristics of their planes to everyone before the individual Product Owners quality checked each team’s work.

Test Flight

And the results if the first Sprint were…

Team G produced no accepted batches, Team P didn’t submit any batches, Team M produced no accepted batches and Team S produced… no accepted batches. Suddenly there was a realisation that this may be trickier than it first appeared.

The Teams then had 2 minutes to consider the 1st Sprint (a sort of Retro) and plan for the second – this produced some fevered team discussion with much waving of hands and pieces of paper. And then we were off. Sprint 2 was counting down…

So the pointy end goes at the front?

So after the Second Sprint the great news was all the Teams managed to produce at least 1 accepted batch of planes but we had a clear winner in Team P who where duly awarded shiny medals for their achievements.

The Top Gun Results

G then wrapped up the session, giving some sources for additional reading, answering questions and taking the attendees to visit a real life Scrum Board in the IT area.

Bingo Fuel*

We certainly demonstrated the benefits of the Iterative approach with teams clearly seeing how the ability to get early feedback, reflect and adapt (demo and retro) produced real results. One aspect that is often overlooked but was well received was the Self Organising aspect of Agile. The concept of the team owning the work rather than being told what (and how) to do it is a tricky idea to describe and actually having to do this opened a few eyes. Finally everyone came away with a new idea for building paper planes.

We’ve had really good feedback from the session and  I really think that we managed to at least give people a flavour of Agile and the benefits.

Thanks also to M and S for accepting their shanghaiing!

* Bingo Fuel: “A pre-briefed amount of fuel for an aircraft that would allow a safe return to the base of intended landing”

The Right Tool for The Job

(Stephen Sowerby – Senior Developer at NCFE)
At NCFE, we have a very collegiate approach to implementing new technologies. As a team, we encourage everyone to go out and look for new technologies and new approaches to problems. Everything is routinely evaluated to ensure we are doing things in the best way possible. Nothing is sacred. And because of this, sometimes even the most simple and prosaic thing can end up under the microscope.

The enum, for example. Simplicity and prosaicism itself. But because of the ability to ‘power-up’ an enum by adding Data Annotations, they can be used for far more than just a number and a value. This ‘power-up’ could be as humble as adding a DisplayName property. But there is nothing to prevent more and more annotations being added, and this can lead to the enum losing some of its simplicity.

We had this exact feeling during one of our recent projects. In our case, the numerous annotations we were using were often defining behaviour for the enum in business logic. This in itself wasn’t so bad, but we were finding that some of this behaviour needed to be replicated in various places in business logic code.

public enum SectionType : int
{
    [Display(Name = "Action Plan For Centre"), MarginBottom = 60, MarginLeft = 20,        MarginRight = 20, MarginTop = 80, Timeout = 2000]
 ActionPlanForCentre = 1, 
    ...
}

This was no longer an innocent, dumb enum; it needed to be treated a bit more carefully, and we needed a better strategy.

The solution that we found came from a talk by Domain-Driven Design enthusiast Jimmy Bogard. As well as some awesome ideas about domain models more generally, in this particular talk Jimmy explores an idea to resolve exactly the issue we were having: enums being used in business logic to make complex decisions, and consequently this logic needing to be replicated in various places.

The refactoring that Jimmy does is seriously impressive, and it prompted a session of pure geek-glee in our team. I won’t narrate the refactoring here – only watching it happen in the demo can do it justice – but the premise is to take the enum and refactor it into a fully-fledged class. This allows the enum to use the full power of object-orientation to encapsulate its own behaviour, polymorphically.

And if that isn’t enough, the refactoring implements the different enum values as static properties so that the classes still feel like enums to use. Cool or what? (https://vimeo.com/43598193)

So, riding a wave of Jimmyfandom, we refactored our first enum to become our very first ‘Bogard Enum’. It was a resounding success. The ifs and switches that that had previously driven the business logic around the behaviour defined in the enum vanished into thin air. Overnight we became evangelists. The textbook definition of the Open-Closed Principle became almost like a mantra, to be heard across the office as someone found another enum that could be Bogardified.

We were about to set out on a bonfire of the enums when we ran into a problem. Although our Bogard Enums felt like enums to use, there was one place that its magic didn’t work.
When serializing a standard enum to JSON for passing to and from a Web API, the model binder knows how to convert a simple integer to the corresponding enum value. This was not so simple with our Bogard Enums. We tried a few things, including creating custom model binders to explicitly define the mapping between an integer and the Bogard Enum, but we couldn’t find a solution that we could roll out everywhere. It always felt like we were dirtying things somehow.

We eventually settled on an implicit conversion method inside each Bogard Enum that showed how to resolve an integer.

public static implicit operator SectionType (int value)
{
    return FromValue<SectionType>(value);
}

This worked, but it meant that every view model class that contained one of our beautiful Bogard Enums also needed to have an integer property that could be used in the conversion.

public int SectionTypeID { get; set; }

public SectionType SectionType
{
    get
        { 
            return (SectionType)this.SectionTypeID;
        }
}

Not bad, but not good. All of a sudden, our conversations about Bogard Enums started to be tinged by a sadness that had never been there before.
…
I recently attended the NDC conference in Oslo. It was packed with excellent talks, including one by Jimmy Bogard. After his talk, I told him about our use of his enum refactoring. I spoke about the success we’d had with it, and the solution that we had come up with to the conversion issue. We discussed the benefits and drawbacks of the technique as a whole and Jimmy, having experienced the same issue we had, seemed happy with the solution we had found. However, our conversation led me to realise, as Jimmy had, that writing enums in this way may solve some problems, but it also creates some others. Jimmy told me that he doesn’t use this refactoring as often as he had thought he might, and had actually found them to create more issues than they solve for all but the most behaviour-heavy enums.

Coming away from that conversation, I felt happy that we had found a good solution to a difficult problem. But I was also left feeling like this wasn’t the panacea that we thought it might be. It was, just like everything else, just another tool in the box.

Back at NCFE, our collection of Bogard Enums is still intact, and continues to grow. But the bonfire of the enums has been cancelled. Just like any other tool or technique that the team has adopted, the Bogard Enum is now used only under the right circumstances: when we want to encapsulate behaviour that would otherwise manifest itself as duplicated business logic code.

And when the right circumstances do arrive, the faint sound of the mantra can still be heard: open for extension, closed for modification.

Splitting Stories

Let me tell you a Story

I’ve been having a little difficulty recently trying to assist the team in breaking down stories into more manageable (as in a single sprint) stories. I’d like to share the results of my research with you.  

Before a user story is ready to be scheduled for implementation in an upcoming iteration, it should be “small enough”, the usual rule of thumb being “a story that can be completed within the iteration”. However, many user stories start out larger than that. “Splitting” consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.

Story Splitting – Agile Alliance

A good story will always follow the INVEST model

• Independent
• Negotiable… and Negotiated
• Valuable
• Estimable
• Small
• Testable

And it is how we reach the Small requirement that this post will focus on.

Why Split a User Story?

Consider a team with a velocity of 20 which commits to two stories each worth 10 points. The team produces work equivalent to 19 story points, meaning only 50% of the stories committed to are completed.

Now consider the same team with the same output, but they have committed to 10 stories each worth 2 points. The team will achieve  90% of the stories committed to.

The benefits of smaller stories also include Improved Understanding, Increase the Accuracy of Estimation and make is Easier to Prioritise for the Product Owner.

It is worth noting that splitting a story is unlikely to reduce the story point total – 8 points will not split nicely into four 2 point stories, but may on the other hand, identify stories where no or little value will be added.

When to Split a User Story?

This will depend on each Team’s Velocity, however, it would seem reasonable to say that the larger the story, the greater the chance of failure and that we would always prefer to complete more than we do not after each sprint.

Going back to our earlier example:

The Team has an established velocity of 20 and commits to two stories at 10 points each, assuming both stories are worked on at the same time there will be a significant chance that neither will be finished at the sprint end – bugs, system problems, and sickness. The sprint has produced nothing and, although the team will potentially catch up in the next sprint, we have to remember the goal of each sprint is to produce “a ‘Done’, useable, and potential releasable product Increment”. Even if we complete one of the stories we have only completed 50% of the committed to work.

Taking this example we can say that any story that is at least 50% of the available velocity (and to err on the side of caution 40% may be a better benchmark) has to be a candidate for splitting.

How Small should a User Story be?

Again this depends on the Team’s Velocity and style. We also need to make sure we do not lose track of the other INVEST principles when seeking to split larger stories (though it may be the case that as we split a story we may find parts that have little or no Value and can so deprioritised or even discarded).

Leading Agile – How Many Stories per Sprint? suggests that each story should be able to be completed (as in ”Done” Done) in 1 to 3 days and suggests 5 to 15 stories per sprint.

This would indicate a size of 10% to 20% of the Team’s Velocity would be a good size to aim for. So if the Team has a velocity of 20, ideally we should split stories down to a size of around 4 points as a maximum. Obviously, there will be cases where we cannot do this but would be a reasonable starting position.

Interestingly the Scrum Breakfast post – What is the Optimal Story Size suggests that the majority of Scrum Teams commit to 4 to 13 stories and the average story size is around 15%.

How to Split a User Story

This section looks at approaches to take to split the stories it’s based (by which I mean plagiarised) heavily on Agilistic – 10 useful strategies for breaking down large user stories and Agile for All – Patterns for Splitting User Stories.

Whenever a story is split, we must continue to ensure the new stories all meet the INVEST principals.

Vertically NOT Horizontally

It is not advisable to split stories horizontally – by horizontally I mean breaking a story up by the type of work needed an example of which would be splitting  by application layer (frontend, backend, database) or development separate to testing.

Breaking up a story this way means that unless all the sub stories are completed no Business Value will be delivered. In addition splitting stories in this way makes it very hard for a Product Owner to prioritise the Backlog – Is the Database Story more or less important than the Frontend Story? It can also reinforce the separation of skills (Database Guy, Frontend Girl, Tester Guy, Coder Girl) that Scrum seeks to dissolve.

Breaking a story down in this way is best left to the team when they create their tasks when determining how they are going to complete the story.

Patterns to Breakdown a User Story (in no specific order (except the last one))

WORKFLOW STEPS

If the story involves any sort of workflow, we should be able to break the story down in the individual steps.

 “As a customer, I can pay for goods in my shopping basket, so that I receive my products at home”

Could be broken down into steps:

“As a customer, I can log-in to my account, so that I don’t have to re-enter my personal information every time”

“As I customer, I can review and confirm my order, so that I can correct any mistakes before I pay”

“As a customer, I can pay for my order with a credit card, so that I can confirm my order”

“As a customer, I receive an email confirming my order, so I have proof or purchase”

BUSINESS RULES

A story may need to implement  a number of business rules and these should be split out.

 “As a customer, I can pay for goods in my shopping basket, so that I receive my products at home”

We may be able to identify (from acceptance criteria) stories which can be tackled separately:

“As the store owner, I can add additional P&P where the order is less than £20”

“As a store owner, I can decline orders from customer outside the UK”

“As a store owner, I can reserve ordered products, so customers see a more realistic stock level”

“As a store owner, I can cancel orders for which I have not received payment within 48 hours, to release stock”.

Any validation a story may have can often be a candidate to split out.

GREEN vs RED PATH

There will often be a Green (everything goes well) and several Red (something isn’t right) paths through a piece of functionality. We can look to split the story into these separate paths.

“As a customer, I can log-in to my account, so that I can access my information”

Can be split into:

GREEN

“As a customer, I can log-in to my account, so that I can access my information”

RED

“As a customer, I can reset my password if necessary, so I can log-in”

“As a customer, I can register a new account, so I can log in”

“As a store owner, I can block customers who incorrectly to log in 3 times, so that I can protect the site”

MANAGE CRUD

The word “Manage” in a story is a strong indicator the story will have multiple operations (Create, Retrieve, Update, and Delete). These operations can clearly be broken out.

“As a customer, I can manage my account, so that my details are correct”

Could break down to:

“As a customer, I can create an account, so that I don’t have to re-enter my details each time”

“As a customer, I can view my account details, so that I can check the details are up to date”

“As a customer, I can edit my account details, so that I keep the details up to date”

MAJOR EFFORT

It may be possible to break a story down where one story (the first) will contain most of the effort and the subsequent stories are additions to the first story.

“As a customer, I can pay for my order with a credit card, so that I can confirm my order”

Could be split down to:

“As a customer, I can pay for my order with VISA, so that I can confirm my order”

“As a customer, I can pay for my order with MC, so that I can confirm my order (given that VISA has already been implemented)”

“As a customer, I can pay for my order with AMEX, so that I can confirm my order (given that VISA has already been implemented)”

VARIATIONS IN DATA

We can split stories based on the data they return or the parameters they may handle.

So for a Data Retrieval story, we could take:

“As a customer, I want to be able to view my orders, so that I can see what I have ordered”

And this could be broken down into steps which add complexity at each stage

“As a customer, I want to view all my orders” – A simple unordered list

“As a customer, I want to view all my orders by date” – Date ordered list

“As a customer, I want to view my orders 10 at a time” – Pagination

“As a customer, I want to view my open orders”

… and so on.

And for a Search story

“As a customer I can search for products so I can view and order them”

Can be split

 “As a customer I can search for products by product number…”

“As a customer I can search for products by product name (exact match)…”

“As a customer I can search for products by product name (fuzzy match)…”

“As a customer I can search for products by price…”

“As a customer I can search for products by type…”

… and so on.

PERFORMANCE

A large part of the effort to complete a story can giving a fast response, but the basic implementation may not be that hard. In this case it makes sense to split the story into “It Works” and “It Works Fast”.

“As a customer, I can search for a product”

Could be broken down into

“As a customer, I can search for a specific product (slow show a searching animation)” – It Works

“As a customer, I can search for a specific product (fast in under X seconds)” – It Works Fast

This may be an occasion where we could split the second part horizontally.

TEST SCENARIOS

We may have a large story where it’s hard to break the story down based purely on functionality alone. In this case, we could consider how the functionality is to be tested. Each test scenario could then become a story in its own right.

“As a store owner, I need to track stock levels, so I can fulfill orders”

Could be broken into Test Scenarios such as:

Test 1 – If stock is at Zero an alert is sent

Test 2 – If stock is less than X units an alert is sent

Test 3 – if stock is Zero, it cannot be ordered

Test 4 – If stock is in a basket it should not be counted as in stock

Test 5 – If an item is ordered by a customer the stock level should be adjusted

Test 6 – When a new stock arrives the stock level should be adjusted

Test 7 – Stock levels can be manually updated after stock takes

Each test can then become a story in its own right.

This pattern can help apply other patterns as we automatically end up with business rules and Red and Green flows and potentially Data variations.

And finally BREAK OUT A SPIKE

A story may be large because we do not fully understand the implementation. If this is a case it may be worthwhile to create a time boxed Design Spike story.

“As a customer, I can pay for my order with VISA, so that I can confirm my order”

We may not know how we implement credit card processing so we can break it down into

“Investigate VISA credit card processing”

“Implement credit card processing”

In the investigate story the acceptance criteria should be the question that needs answering. Once we have answers to the stories we should stop.

Which Pattern to Use?

Agile for All – Patterns for Splitting User Stories suggests two useful Rules of Thumb for choosing patterns.

• The pattern that lets you deprioritise or throw away a story. Think of the 80/20 rule!
• The pattern that produces more equally sized small stories – 8 points to 4 x 2 is better than a 5 and a 3.

Summary

We need to stick to the INVEST principals when splitting stories and look to split vertically (by function) rather than horizontally (by architecture).

Splitting stories will be an additional overhead on the team but will produce benefits. We can use one or more of the described patterns to help us drive the process.

We should always bear in mind that splitting a story may increase the total story points in the backlog – an 8 point story is unlikely to split into just four 2 point stories.

We should strive to make sure our stories are no larger than 40% of the team’s velocity and preferably only around 10-20% of the velocity.

Good stories should be small. This makes then clearer, easier to prioritise and estimate, quicker to implement and so faster to deliver value.

Some additional stuff

Agilistic – 10 useful strategies for breaking down large user stories

Agile for All – Patterns for Splitting User Stories

A Useful Flowchart from Agile for All

Mike Cohn on Splitting Epics

Lessons from my four year old

This morning my little boy put his Spiderman watch on.  “Ok, no big deal” you might think, but he’s only four.  He persevered with the strap and fastened the buckle without any impatience.  He was totally focussed and carried on until he had his watch on his wrist.  He then looked up at me and, proud as punch, asked “Mammy, is that right?”

I had a split second to decide whether to tell him it was upside down – would he be disappointed or upset?  Would it lead to an early morning melt-down?  It wouldn’t really matter if it was upside down all day, he can’t tell the time anyway!  But I decided to tell him, and then held my breath for his reaction.

“Ok” he said, as he concentrated on contorting his wrist, in the way only a bendy four year old can do.  “Like that?” he said, once he’d managed to rotate his entire arm so that Spiderman was the right way around.

Once I’d told him that was right, he took the watch off, turned it around then placed it on his arm but before he started on the job of fastening it he looked up at me and once again asked “Is that right?”  I said it was and he set to work on the tricky fastening.  He managed it, all by himself then skipped happily away with Spiderman the right way round.

This whole interaction lasted probably 5 minutes, but it stayed with me right through the school run and the inevitable traffic jam on the way to the office.  My little boy had instinctively done something that us grown-ups can struggle with.  He’d sought confirmation that what he’d done was right, and when he found out it wasn’t he corrected it.  Not only that, as he was correcting his mistake, he made sure that he checked he was still on the right track before he went too far.  No ego, no drama, just a simple “Is that right?”

It’s a lesson we could all probably learn from.  It’s tempting to rush ahead when we think we know what we’re doing.  We can get so involved in the tricky bits, like fastening the watch strap, we forget to ask if what we’re doing is right.

The evolution of Software Testing within the Software Delivery team

Over the past 3 years, the techniques we apply and tools we use  for software testing within the IT Software Delivery team at NCFE has evolved radically, helping us to ensure the highest level of quality in the software we deliver.   Below is a little bit from Ron Bell on the evolution of Software Testing within the team.

Day to day we used to follow scripted tests, which were a series of instructions similar to following directions from a training manual.  On reflection, we decided that we wanted to take a different approach. There was a danger that, because we were just following the exact steps to make the system work as it should, we weren’t likely to find any significant flaws within the software.  DOH!!!  Hence we adopted a more exploratory-based testing approach.

You might ask yourself what is Exploratory Testing?  In a nutshell the clue is in the title – it’s about exploring the system.  This is still a highly disciplined approach to testing, but it uses more of the tester’s skill and experience to focus on the areas that are likely to need more attention.  Using our new approach, we started using the system in a less prescribed manner to better reflect an everyday user.  Real life system users carry out tasks in their own, often different ways to achieve the same result – this doesn’t mean the user is using the software incorrectly, as a key element of exploratory testing is acceptance that there’s more than one way to achieve the same end goal.

Following this approach we found far more relevant high and critical level defects within our development projects, those that had to be fixed prior to software being released.  In my opinion, this means that had we stuck with our old approach of using scripted test steps, the quality of the software we released to the business would not be of as high a quality as it is.  That is not to say that scripted tests don’t have value, but now we have the freedom to use whichever approach is best suited to the project.

A lot of the work we carry out as Testers during the development of software is Regression testing, which is the process of retesting existing functionality to ensure nothing has been broken when the changes were introduced.  This is something that’s almost inevitable when you’re developing new software of any complexity, that’s just the nature of the beast.  Regression testing is vital to all software development, but as Testers we used to have to carry this out manually which was a consumption of resource within the Software Delivery team.  Since those dark days, we now have an Automated Test framework in place throughout all projects within the Software Delivery team.

Our automated framework runs a series of tests for the existing software functionality within a project and we can also add to the coverage by writing new tests for any new functionality that is developed.  Automation has been a huge step forward as it frees up test resource within projects to concentrate on the more human aspects of the role – a machine cannot check for charisma, usability etc.  Automation can be far quicker than testing manually, can be relied upon to complete the same steps every time with no deviations and encourages quality – failing tests can quickly identify if anything has broken, ensuring we get the opportunity to fix it prior to the software being released.  Our automated tests can be scheduled to run on a daily basis or we’re able to kick them off ad-hoc.

The overarching moral within this blog is never stay static as it’s an ever changing and demanding world out there – there’s always room for improvement!

I hope this has been informative, if you do want to hear more though, please let us know, our doors is always open.

Six Thinking Hats®

Six Hat Thinking in a software delivery world

Some months ago I was lucky enough to get take part in some soft skill training at NCFE. This training involved looking at Edward de Bono’s Six Thinking Hats® and I thought I would share what I learned here.

The Six Thinking Hats® technique was developed in the 80’s and is found everywhere, many schools and business teach it and it is a very useful technique to know and use when you or your team struggling to reach a decision on something.

If you have never heard of it is worth a having a look to see if it would help you or your team, ill run through the basics here but a lot more information can be found online and in books written by Edward de Bono. The idea is to think about something in a single way and then move on to a different way until a decision has been made. You control your thinking by imagining wearing five different coloured hats, with the sixth hat being used to manage the process.

	White for the known facts or information.
	Yellow for thinking about the logical positive benefits.
	Black for thinking about the logical negative aspects like issues and possible problems.
	Green for generating ideas and solving problems and thinking creatively.
	Red for intuitive or automatic gut reactions.
	Finally Blue for managing the process and keeping everyone on track.

These hats can be used in any order and the sequence and how long to spend on each section is worked out by the nominated blue hat before the meeting. It is worth remembering not all hats need to be used and the use can be repeated. During the meeting, others can become the blue hat for a time as the blue hat should not take an active part only control and steer the meeting if the person has something to say on a section which is the blue hat they can pass control for that section to someone else. Also, if someone feels the meeting is going off track, he or she can declare they are putting on the blue hat to bring it back.

In most cases White is prepared beforehand by the blue hat and can be facts and figures or information that has been given to you. Other members of the team can contribute to the white section and can include things others have told them outside the team that may or may not be true (it is still a fact).

Yellow and black are normally used together when thinking about an idea to get all the positive and then risks around it but it can also be used for any time you need to think logically in an optimistic or pessimistic was, the key here is being logical – feeling should not be involved.

Green is used when you need to gather new ideas or think outside the box, this can be simply getting everyone to shout out ideas to doing a formal process, there are tonnes of useful tools to do this including Mind mapping, Random Word Generation and Lateral Thinking.

Finally, there is the red hat, the emotional part. A red section should be short – something like five words or fewer, Thumbs up or down, or a score out of ten. The answer should never be justified and a final decision should always be made using the red hat.

Like most ideas it looks quite basic on paper but the practice can become a powerful tool. This technique can be used in teams or individually and when used well speeds up decision making. Over the next few months, I’m going to be trying to use this in my working life and if I have any great successes with it ill discuss it here.

Thanks for reading

Simon Longshaw
Software Developer, Software Delivery (Maintenance), NCFE
 View my LinkedIn profile

Credits:
Six Thinking Hats® was developed by Edward de Bono and published in 1985.
Hat photos used in this post have come from sunshinetalia Flickr album with thanks.

From GCSEs to Work

Chelsea is currently a junior software tester at NCFE. She joined us through an apprenticeship scheme and in this post she explains why she wanted to take this route and how she thinks this has helped her career.

When my exams came to an end, I knew I wanted to go straight into a working environment. I think this was because I wanted hands on experience and I wanted to go into a specified role. The thought of sitting in a classroom every day for the next two years didn’t appeal to me. I didn’t want to have the same qualifications as everyone else, as after two years there would be no distinguishing between students who have A levels but no work experience. However, I was a bit worried about not having A levels which I thought would set me back. With this in mind wanting further qualifications and work experience, the best option for me was to find an apprenticeship.

When it was getting closer to finishing my exams I started to look online for apprenticeships not really knowing what I wanted to do exactly. I narrowed it down to IT because I thought this is something I want to learn when looking at careers and also it wasn’t a subject I did in school but interested me. With this interest I applied for a lot of IT apprenticeships.

A few weeks later I got a text from a Baltic Training Services saying they had a 15 week IT boot-camp in my area. I thought I’d go to the introduction to check out what this boot-camp was all about. I came out of the introduction meeting knowing that the boot-camp was something I wanted to do and I would hear back if I got a chance to go for an interview. A week later I got a phone call saying I could go for an interview at NCFE for the boot-camp. At this point I was worried that with the experience and no IT qualifications it might hold me back. I was told that the boot-camp was for people with a keen interest and qualifications wasn’t a big factor as this is something I will learn. I was successful in getting a place on the boot-camp with 8 others.

The boot-camp was held at NCFE and me and the other learners were trained by Baltic Training. It was a big leap to go onto a boot-camp with 8 other new people. I was the only girl and the youngest in the boot-camp. At the start I thought this would be intimidating but when I got to know everyone it was great. When we signed up for this boot-camp we knew there was going to be roles for development, testing, infrastructure and social media. At the end of the boot-camp we had the chance to get interviewed for up to two roles.

The interview process for the apprentice roles lasted 2 days. Once the interviews were over, we found out on the second day who had been successful and who had what role. I managed to get the software tester role which I was ecstatic about. After this the learners who didn’t manage to get a role, NCFE and Baltic Training supported them in finding an apprenticeship elsewhere, where they could do the Level 3 diploma and get work experience.

When boot-camp was finished I started my own Level 3 apprenticeship at NCFE. Straight away I was sat with the test team learning business and technical knowledge. A couple of months later when I had some experience I was sat with the Test Analyst to see how coding helps testers and was trusted enough to be allowed to try some myself. Being put on one of the biggest projects at the time really pushed me to get involved and do my best to help out whilst learning.

At the end of my Level 3 apprenticeship a year later, December 2015, I was recognised by Baltic Training as Apprentice of the Year, and then I was offered a Junior Tester role at NCFE. At the end of my level 3, Baltic Training offered me to take on the level 4. When Baltic first asked I was a bit concerned that I wouldn’t be capable and I thought it could get in the way of my Software Testing role. When I started thinking about it and talking to others, I soon realised that the Software Development course would really help me in my role and that I was capable in succeeding.

Coming into the working environment has given me a massive boost of confidence. I now feel like I can do more independently than I could when I was in school. I can honestly say I wouldn’t change anything I have done to get to this position from school. I’m now in the work place with experience and a real career with options for the future. I would totally recommend an apprenticeship to anyone looking to get hands on experience whilst still learning.

Written by Chelsea Dryden (Junior Software Tester)

 

Star Wars Episode VIII – The Myers Briggs Type is Indicated

Welcome, young Skywalker. I have been expecting you.

A Friday afternoon conversation arose on the Myers Briggs Type Indicator and the Star Wars interpretation of the results, mainly due to one of the team discovering that he was in fact Padme and was curious to see who else we had on the team.

You will reveal your personality type…

The Myers Briggs Type Indicator is “an introspective self report questionnaire designed to indicate psychological preferences in how people perceive the world and make decisions”.

This led naturally to an outbreak of test taking (well it was Friday) for those of us who hadn’t taken the test already (we used the free Jung Typology Test) and discovering our true nature (using the Star Wars Characters Myers-Briggs Personality Types). Some of those who already had a rating also took the free test and came up with same result.

Now as a Gemini I’m naturally cynical about any attempt to match people to a set pattern but some curious results emerged.

These are the MBTIs you are looking for…

It is unavoidable. It is your destiny.

Out of 16 (admittedly a small sample), we had 6 Emperors (INTJ), 4 Qui-Gons (ENFP), 2 Padmes (ENFJ), 1 Yoda (INTP), 1 Owen Lars (ISTJ), 1 Wicket (ESFP) and a Darth (ESTJ)

What’s interesting is that Emperors are supposedly only 2.1% of the population, Qui-Gons 8.1%,  Yodas 3.3% and Padmes 2.5%!

Frequency	Expected %	Actual %
Emperor	2.1	37.5
Qui-Gon	8.1	25.0
Padme	2.5	12.5
Yoda	3.3	6.25
Owen Lars	11.6	6.25
Darth Vader	8.7	6.25
Wicket	8.5	6.25

Fortunately we had no Jar Jars (Expected Frequency 12.3%) or C-3POs (Expected Frequency 13.8%).

Only now, at the end, do you understand.

Looking at the suggested careers for MBTI results, IT seems to be an area where you’d expect to find Emperors – which makes sense for these “bewilderingly deep and intelligent people”.

But do these high levels of Emperors in our team contradict the Rule of Two and so will lead to the downfall of the IT Department Sith?

So what’s your character and do you feel that too many Emperors could lead to the end of the Empire?

PS: Yes I am an Emperor…

From customer service to QA testing…

My journey from customer service to  QA testing

I have been working now in the testing discipline within the Software Delivery team for the last 3 years. I used to be a Centre Support Assistant (CSA) dealing with the front line customer service which involved supporting schools and colleges running NCFE qualifications. This entailed releasing external exam results, visiting new centres and training staff, maintaining up-to-date details for centres, handling queries and complaints, promoting NCFE qualifications and services and working with the business development team.

My transition from being a CSA to becoming a Quality Assurance Software Tester within IT, working as part of an Agile development team has been both uphill but very rewarding.  My 14 years of working as a CSA really taught me how valuable the interaction between the company’s external facing systems is and that getting this right with the minimum of bugs and issues being reported by our end users ultimately help us to achieve the very high levels of customer engagement that we at NCFE strive for. This really helped me when I first became interested in software testing whilst still in my role as a CSA. As part of NCFE’s quality checks, we have a User Acceptance Testing phase on our projects which is where people from the business test new software before it is delivered to the company internally, or deployed to our external systems for our customers to use. From doing this I was successful in applying for a vacancy within the Software Delivery Team for a Quality Assurance Software Tester.

My first few weeks as a Quality Assurance Software Tester within software delivery were what I can only describe as massively diverse and a challenging learning curve, the challenges of working in an IT team as opposed to a customer service team and changing work practices after 14 years were not insignificant. That aside, although I felt in the deep end initially, it has benefited me immensely in terms of the new skills and knowledge I’ve gained. It has also been an eye opener being able to see how IT develop and test the software they produce, as during my time as a CSA I never actually realised the sheer amount of time, effort and teamwork that was involved.

My first couple of months within the team were spent shadowing the existing Testers and Test Analyst within the department to learn about the techniques they used for QA testing.

There was a whole raft of knowledge and learning I had to take on board that at first hurt my head but gradually became memory muscle, some examples are:

• Learning about Agile and working within a Scrum team which we use on software delivery projects.
• Working with Microsoft SQL Server Databases and learning how to write SQL scripts to interrogate databases.
• Learning about the deployment of code to an environment and putting this into          practice on a daily basis.
• Learning about Estimation of user stories within projects.
• Working with PowerShell scripts and learning how to edit these for the deploying code to various environments.
• Learning how to configure of database, application and BizTalk servers within test    environments which is put into practice on each new project.
• Introduced to Automation writing Software testing and writing automated tests.
• Learned basic C# skills to help with Automation which is currently written in C#.
• Undertook the ISTQB Advanced Test Analyst course.
• ISTQB Foundation Level Certificate in Software Testing gained qualification me as a   fully certificated Software Tester.

There will doubtless be something I’ve forgotten to list above.  Even though I’ve learnt so much I’m still learning and gaining new knowledge – love learning, always learning.

I’ve never regretted my change in career, being someone that came into IT from a different department, I will vouch for the fact that most people probably don’t realise what we do in software delivery and if you love a challenge and learning completely new skills then I’d recommend you check us out sometime!

 

by Ron Bell (software tester)

Do businesses need software testers?

I recently attended the North East Agile testing meet up held at Campus North in Newcastle. A really interesting question was asked: “Do businesses need software testers?” An example was provided in the form of Yahoo who have eliminated 15% of its workforce including its test and quality assurance teams as it moved towards continuous delivery via automation. An uneasy shift that they suggest will result in fewer errors by removing the human factor.

• could this really be the way forward?
• are software testers a thing of the past?
• is it really the rise of the machines?

Man vs Machine

Machines have not reached an AI state you will be glad to hear so automation is based on human imagination and input. In that regard we still have the issue that if the input code is wrong, so is your output. No difference from manual testing other than the automation code will always run the test the same way until the error is discovered and fixed (by a human).

• Automation helps the software tester perform repetitive tasks such as regression testing.
• It runs 24/7 allowing a tester to run more test after their working day is over

Perhaps a flaw that works in our favour as humans is that we exhibit natural variances. We can follow test steps but we might hit the wrong key or press the wrong button that yields unexpected results in the software under test. Our attention span might waver and we step off the defined path to see “what happens if I”. Automated scripts never waver, they can’t think for themselves. So there’s no need to befriend John Connor on Facebook just yet.

Food for thought – how much trust would you put in automation alone?

Scenario: You are sitting in the back seat of a Google driverless car. You can see the road ahead but can’t access the steering wheel or brake.

Are you the type of person that trusts automated tests have eradicated major issues and the system has enough scenarios programed into it to identify hazards and take corrective action? Or, do you want to sit in the front seat, just in case?

Conclusion

Yahoo’s radical approach might not be for every business. In the end it might transpire that it was simply a streamlining exercise in a diminishing marketplace.

The Google driverless car scenario might be the real reason why businesses are not jumping on the Yahoo bandwagon and throwing the testers out with the bath water? Businesses are adopting similar approaches but in smaller bites as they transition to continuous delivery. Rather than a radical cull of testers they invest in them and up skill them as part of the transition, realising the valuable asset they are to the grown of the business.

---

Post written by Jack Joyce (software tester)