SEUs and Practical Agile


As you will all hopefully be aware the Scrum Alliance is adding a continuing education component to many of it’s certifications from February 2019.

Certification (Two-Year Term) SEUs Required Fee Per Term
Foundational: CSM®, CSPO®, or CSD® 20 (NEW!) $100
Advanced: A-CSMSM or A-CSPOSM 30 (NEW!) $175
Professional: CSP®-SM, CSP®-PO, or CSP® 40 $250

There are several ways of gaining SEUs for example


Fortunately our very own Newcastle Practical Agile is endorsed by the Scrum Alliance and by attending you can claim up to 2 SEUs each time!

So why not come along for some informal discussion about real world Agile matters, normally the 1st Tuesday of every month. Find out more details on our meetup page (

Hope to see you soon!

Find out more about gain SEUs at Scrum Alliance – Scrum Education Units (SEUs)


New Venue for Practical Agile

Since its inception in April 2016, Practical Agile has predominantly been hosted at NCFE’s offices at Quorum Business Park, however from August 2018 we have a new home at Newcastle University’s campus.

This location being more central will hopefully enable more people to attend  in time for the 6pm start.

The venue for September’s meetup is the Howden Room in the King George VI building on Queen Victoria Road (opposite the Royal Victoria Infirmary’s main entrance)



Finding your way to the venue can be a little tricky if you don’t know the campus well, especially if you rely on putting a postcode into google maps or a sat nav, as the postcode for the university takes you to a totally different part of campus.

This link shows you the location of the building on Google Maps but if you want more specific directions and use the What3Words app which gives you directions down to a 3x3m square plot of land anywhere in the world, the location of the entrance to the building is ///props.closes.hint

We look forward to seeing you there in September.


How do you do long term planning when your organisation needs deadlines and lead times?

Practical Agile went on the road for December and was very kindly hosted by Opencast.  As I couldn’t just walk downstairs this time I was a little late and found the discussion in full flow.

The conversation revolved around an interesting situation where negotiations were underway to deliver a project where a specific set of functionality had to be delivered by a specific date in order to secure funding. As part of the proposed contract punitive clauses would be applied if delivery was not made.

The first question raised was if Scrum was the best framework for tackling this work given a fixed specification and delivery date? Unsurprisingly – this being an Agile group – the feeling seemed to be this would not be an issue and that a more traditional approach such as waterfall would be more prone to failure. The team should be able to experiment, prototype and then harden and this fits well within a Scrum Inspect and Adapt cycle.

In order to avoid the penalties it is vital that the essential Core Functionality that must be delivered to ensure that the funding is received is identified and prioritised as such.

I Love It when a No Plan Survives Contact with the Enemy Comes Together

Given that (as part of the contract) we have a very well defined specification we should have a good understanding of what must be delivered.  Concerns were expressed that this may stifle innovation and learning from the development team. Including the Development Team (not necessarily the full team all the time) in the discovery up front would ideally lead us to a situation where the WHAT is rigidly defined but there is wiggle room on the HOW.

However common experience told us that no set of requirements ever fully defines the product and that we will always want to make sure we set aside a suitable percentage of time for scope creep.

In addition non-functional requirements such as Performance, Stress and User Testing and Documentation such as User Guides are scoped and agreed up front and suitable stories created to support these activities.

With a hard dead line it’s vital the client is available and that Product Owner is empowered to quickly respond Yes or No if necessary.

In order to support the project the Definition of Done needs to be formalised and agreed. This will stop any misunderstanding or confusion about whether the contract has been met.

It’s not You, It’s M… Well It’s Them Actually

Involvement of 3rd parties was felt to be a potential source of pain.

It needs to be very clear what would happen if a 3rd party failed to deliver, with the impact that the project missed the deadline. What would this mean to the triggering of any punitive clauses?

Direct communications with any 3rd parties should to be firmly in place and it is essential that these be open and honest. The exact expectations from all sides would need to be clearly set out as would the responsibilities of all parties.

Bare Minimum Viable Product Or Minimum Marketable Product?

If getting paid is dependent on delivering the core functionality to the deadlines do we have any reason to go further than that? In addition would there be temptation to fudge the solution leaving lots of technical debt?

Several reasons were suggested as to why more than just the core functionality would be delivered. These included increased chance of an extension to the contract, repeat business for other projects and the desire to do the best job possible.

Teams would always seek to minimise technical debt purely out of a sense of pride in their work and professionalism.  On a less altruistic motive they would always seek to reduce the support overhead that technical debt means.

And Finally…

Having a rigid set of requirements with a hard deadline doesn’t mean that Scrum isn’t the appropriate framework to use for the project. It is a framework and does not say how the work is to be done!

Isn’t every project a fixed budget project? (at least to begin with!)

And that sort of covers a very interesting and lively discussion. All that remains is to wish everyone Best Wishes for the Festive Season and thanks again to Opencast.

We’re taking January off so Look forward to see you all again in February when we’ll be once again back at NCFE!

October Meetup Cancelled

Hi Everyone,

Apologies for the late notice, but we have to cancel tonight’s October Practical Agile session. Unfortunately due to unforeseen circumstances we don’t have anyone available to host the session tonight.
November’s session will remain on 7th as arranged, We look forward to seeing you there.

Paul, Jon, Nichola and Graham.

Perfect Software – The Enemy of Rapid Delivery?

We all want things to be perfect, right?  But are we making software delivery much harder for ourselves in the strive for perfection?


But, who is it that defines perfect?  Is it the Architect?  The Product Owner?  Maybe… Who knows! – it seems to differ from one organisation to the next.  Whose version of perfection are you trying to meet?

Imagine a scenario where you are unable to release version one of your software because your architect is demanding answers about version 2 and 3 – which you know that you’re never likely to get to anyway.  You’d be feeling pretty frustrated.  On the flip side, being prompted about the plans for V2 could mean you totally rethink the way you’ve done V1, saving time and effort later.



Then someone says “Make it future proof”.

What does this even mean?

And is that future ever going to come?



In a perfect world, to be able to release perfect software we would need to make small changes regularly rather than large releases.  We would also need to have full control over:

  • The requirements
  • The development and test environments
  • The target environment
  • The release mechanism
  • Probably the users too…!

So rather than perfect, should we be striving for Good Enough?  It will depend on the team culture and how risk averse the company are.  This can be influenced by how quickly problems can be fixed, the size of the user base and how exposed any issues would be.  During Spotify’s video describing their engineering model (here) they talk about one of their motto’s – “Never Wrong Long”.  They can release more frequently because wherever possible they deal in small changes rather than large projects.  They also have the advantage that their architecture is decoupled enough that any problems would have a smaller area of impact and any problems can be resolved quickly.

So, is perfect software the enemy of rapid delivery?  It depends on many factors.  It seems to me that the ideal would be to have small, frequent, iterative deliveries that are quick and painless to release – then if it doesn’t meet someone’s idea of perfect, it can be quickly revisited.


Communication in Agile Teams

The second of the April Practical Agile’s Meetup discussions concerned communication in Agile teams.
Tin Can Phone

The first subject that came up was how do you signal your availability to communicate? A “Headphone” standard was proposed as follows:

  • Both Headphones in – I’m in the zone. Leave me alone. Send me an eMessage.
  • One Headphone in – I’m busy but available to communicate.
  • No Headphones in – I’m eager to communicate.

This did lead to the question of how much headphone usage was acceptable? We’d hope that in a self organising team that individual would be putting the needs of the team first and would be actively listening and ready to contribute as necessary – not just to their immediate team, but to the whole .  If the job is getting done is there a problem? It goes back to the concept of T-Shaped People.

How much communication needs to be recorded was a clear topic. The Agile Manifesto values “Working software over comprehensive documentation” but we need to remember that the documentation side still has value. An interesting perspective was that the User Story was a promise to have a conversation. Decisions should be logged somehow – and the use of tools such as TFS and Jira can be easily used to record PO decisions etc. The standard rule of thumb seems to be if you need to ask the question record the answer.

An interesting perspective was that the User Story was a promise to have a conversation – which aligns with the Agile Manifesto valuing “Customer collaboration over contract negotiation”.

Over communication can be a problem with “Reply To All” being regarded as the work of the devil – though perhaps the original emailer may be to blame for distributing it too widely in the first place?

Definition of Ready can be useful by clarifying what criteria is needed to start and leading to discussion of If and Why a story is not ready. BDD and Given-When-Then style criteria (Gherkin) can help clarify any issues and pick out any assumptions,

A team needs to be realistic and be comfortable that some of the finer detail can be thrashed out once the story has been started. The team should be empowered enough can consider whether they feeling any “missing” details are within the remit of the team to determine.

Amigo sessions were once again highlighted as useful tool – helping to kick off communication and common understanding.

It was raised that a mature team’s definition of ready can be unspoken, but on the other hand this could cause confusion for any new joiners.

Who would cross the Bridge of Death must answer me these standard questions three, ere the other side he see

Monty Python and the Holy Grail - The Bridgekeeper

What is your name? What is your quest? What is the average velocity of a 2 week sprint?

The daily Stand-ups were discussed. The value of the 3 standard questions was questioned. An opinion that a simple update as to what you were working on should suffice as the team should already be aware of any issues and problems was generally agreed with.

The Stand-up can also be used as a check before any new work is started that there are no in-play tasks that could be assisted with. The team need to be focusing on the bigger picture rather than just their “own” tasks and a Story isn’t done till it’s all done.

A useful Stand-up tool that has been mentioned before was a confidence check.  After the updates  each participant gives their confidence in completing the Sprint goals by revealing a number of fingers – Five for Very Confident to One for Very Worried. This can stimulate conversation and potentially address problems early by focusing the team on them.

Finally, I think what really ran through the discussion is that Communication is about Respect. I’m off to put on my headphones and look forward to seeing you next time.