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)


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.

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.

What is the perfect office environment for agile development?

The first of the April Practical Agile Meetup’s  conversations was about the best environment for agile development.

Disney Castle

When you develop upon a star…

And the first thoughts were “It Depends”.  Different stages of the development have different needs. Discovery needs a space for discussion, Development needs somewhere to sit.  A fixed space is bad and teams ideally should be able to determine their own layout (taking into consideration Health and Safety requirements).

The Disney Brainstorming Method was brought up. This is a process for creating and refining new ideas using Dreamer, Realist and Spoiler point of view.  The idea is using 3 separate rooms where only the Dreamer POV is allowed in the first, only Realist POV is the second and only Spoiler POV in the third. The idea behind this is many ideas can be examined and refined without stifling initial creativity.

Whiteboards proved a great source for discussion, with many teams using them to partition off their workspaces in open plan offices in addition to their more traditional role as scrum boards and idea capture.

It was felt that all too often that everything gets written down and they can quickly become noisy and out of date. We’ve all encountered the lonely whiteboard in a deserted room with “please do not clean” scrawled on it. If it’s important why not take a photo and then it can be filed and shared as needed and the board is ready to be used again?

The group discussed the virtues of Physical vs Virtual  Scrum boards. Many teams used both which led to the question of which one showed the reality? The majority opinion was it would be the electronic version but that it needs to be used properly with team members burning down estimates and making sure tasks and stories were updated in a timely manner.

The duplication of information has a potential of causing confusion and in some cases the Scrum Master updated the physical board to make sure it reflects the virtual board.

Many teams have large monitors to display the team metric. One point of view was that this can be seen as a pure PR exercise to show internal and external customers that this is a high tech hub activity. However real time data can be very useful to the team where it is appropriate and desired – for example build health.

The need for a public display of information was felt to be an important part of the Transparency needed for Agile by making easily visible the progress and status of work to the team, stakeholders and other teams. Again this brings up the need to identify what is needed and useful to communicate to the wider audience as well as the team.

One common issue always seems to be noise level; My team has a healthy buzz, Your team is making a racket. Communication is central to agile. Tolerance and Respect for each other would seem to be the solution, with team members feeling comfortable enough to call out when there are issues.

As an offshoot from the main topic under discussion, an interesting method of dealing with tardy team members ( a general sore point for everyone) was suggested. At every meeting an individual is late for a mark is tallied against their name.  At the end of the week/sprint the team member with the most tardy marks buys the treats.

Clock Cake

There’s always time for cake!

Developer-centric Teams

The second conversation of our March Practical Agile session was kicked off from the question –

“How do you prevent teams and discussions being dominated by developers?”

The God-King Xerxes

All the God-King Xerxes requires is this: a simple offering of Code and Test

The first reactions were that it wasn’t necessarily the developers who dominated, but that it was not an uncommon scenario.

The underlying issue seemed to relate to the culture of the team and wider business especially where a more traditional waterfall mindset was the norm.

Other problems seemed to relate to the state of stories and it was felt that making sure we have a good and well understood definition of “Ready” (to start work) was available as if we know and are satisfied that the story was ready we also have a firm grasp when it would be done. This can cause problems though if the team try and use this as an excuse not to commit to a story and an appreciation that  “Ready” means “Good enough to Start” with an understanding that some of the finer detail can only be drawn out once work is underway.  On the other hand this cannot be allowed to lead to Feature Creep of the Story with the temptation to add “just one more thing”.

The Three Amigos approach where a Coder, a Tester and a Business Analyst go over each story in an informal kick-off session to give a common shared vision of what will be delivered and helps ensure that it is the voice of the team rather than just a single opinion. As well as helping to prevent domination by one area, the 3 Amigos helps communication between the disciplines and promotes understanding of the work required from each area; Development may be relatively straight forward but the test effort is significant (or vice versa). This closer working helps that understanding of what  all sides need to get the story into “Done”.

One area which could drive the perception of developer pushiness is in the technical detail and especially technical debt. It is felt that Product Owners may not appreciate the reasons and value of the technical side and the team needs to be clear about why this needs to be tackled early and the benefits both short (the system will perform better) and longer (future development will be more difficult and take longer) need to be be made clear. For example a conversation along the lines of if we take x hours to correct the code now we will save y hours developing future stories helps clarify that value of doing things correctly in the first place. On the other hand, developers do need to be realistic and there may well be reasons that a feature is needed now – ideally both business and development team need to understand why and what that is driving their needs.

In all cases the Scrum Master has a key role in managing any negative perceptions of dominance. They need to facilitate the ceremonies and meetings to enable all voices to be heard and valued.  They should make space to allow technical requirements and debt to become valued stories and not just an afterthought. The Scrum Master needs to protect the team by identifying and stopping Story Scope creep, encouraging the Product Owner to spin off a new story to address any new/missing requirement not identified when the Story was committed to the Sprint where reasonable, but also making sure that a Story is not approved where the minor details still need to be refined.

Finally what is needed is Respect from all sides, Communication leading to joint understanding of the project , and clear Value for what we are creating.