Scrutinising The Product Vision


Why fix something that’s not broken? Or so goes the old saying. When implementing change in business, there are often a wide range of reasons that the choice is made to do so. Often there is a need to react to an ever growing market of competition and to keep up with the digitalisation of services. Sometimes something breaks and it’s decided it must be fixed. In some cases it’s someone’s job to come up with snazzy new ideas that cost the company millions of pounds, and any new idea gets sanctioned regardless of its business value.

What we call the “Product Vision” is whatever it is we are setting out to change and attached to this should be a problem statement. I.e what are we trying to solve? If I make a change to something in my personal life, I tend to weigh it up very carefully. Granted, if it’s a choice between a pizza or an Indian takeaway on a Friday evening, I’m more frivolous (I might even have both). However, if I’m changing broadband supplier for example, I analyse the options very carefully indeed. How much is it going to cost? What is the impact of me switching over? What happens if I do nothing and stick with what I’ve got?

From working across a variety of businesses over the years, I’ve noticed how commonly these fundamental questions get overlooked. Do business case templates get populated and sanctioned? Sure. Do those business cases get revisited throughout the project lifecycle and adapted appropriately as things change? Sometimes. Do those business cases get revisited at the end of the project to see if we achieved what we set out to? Significantly less often.

As a Business Analyst, I find projects are much more successful when given the opportunity to scrutinise the proposal as far as I possibly can, asking the all-important “why?” questions. Often this leads to the proposal becoming something completely different. The product that was first proposed has transformed. On some occasions it turns out there isn’t actually a problem to solve.

Change can be very attractive for statistics, to be seen to be “doing something” and an attempt to make a business better or more profitable. However, the time taken over the scrutiny of an idea at the beginning is one of the most valuable exercises any business can execute. It’s always tempting to get the ball rolling as quickly as possible, but taking time to talk with the right people about the problem statement is not something to be overlooked.

Some of the best pieces of work I’ve been part of have concluded with the business collectively saying, “We actually don’t need to change this thing we thought we needed to. We’d be better spending our money on this other thing that’s cheaper and more effective than a multi-million pound project.”

If you set off in your car and you realise you’re driving in the wrong direction for your destination, do you change course? Even the most stubborn of us would admit we’d get back on track, so why do so many businesses decide not to stop, think about things and look for the right direction?

Similarly, it’s never too late to scrutinise the product vision. Granted, it’s much more lean and effective to do so at the start, but it’s certainly not too late once a project is in flight.

It can be scary to be the one voice saying that something isn’t right. It’s difficult when you’re paid to improve business performance, to admit that we need to change how we do things. Or we got this wrong on this occasion. But think how much more can be achieved if we do use that voice.

Be honest, transparent and realistic, and dare to drive the car to the place you actually need to go to.

Let us know your thoughts.


Going digital for the benefit of the people?


So it was that time of year again. The time when you get a letter from HMRC and you can see it looks pretty formal inside the envelope. So I gingerly opened it up and to my delight it was a refund of overpaid taxes. I’m not sure how that’s happened and it’s not a big amount, but it’s in my favour and I’m going to claim it.

Now, it’s been quite some time since I dealt with HMRC. The last time I had something like this, it was for an underpayment and they just adjusted my tax code. No bother. But here I was given the choice – I can receive a cheque in the post in a few weeks’ time or I can use the new digital route and get it in three days. Not wanting to keep my beer money out of reach for too long, I went the digital route…

As I said, it’s been some time. So I’m faced with signing up to HMRC’s service – Government Gateway beckons. Happily, it’s been thoroughly renovated since those days of dial-up internet and the multi-coloured self-assessment pages. Off I went to get my passport, popped a few details in and bingo! A fully-fledged account was set up in minutes. And it knew why I was there. A couple of button presses later to enter some payment details and I was done. Easy.

This feeds into a conversation we had at work the other day. Why force people to use digital services that don’t work for them? As a current example, there’s talk about the NHS using AI instead of face-to-face GP appointments for routine screening checks. But this doesn’t work for certain areas of society. So, instead of forcing people, be inclusive and offer some choices like I had above. When the digital solution is better/faster/more convenient, then the public will follow. After all, who goes to the bank to stand in a queue to withdraw money at lunchtime these days?


Coaching In Agile


In a recent survey, when asked what the most valuable things were that helped businesses to scale agile practices*, the most popular answers given by participants were the following:

  1. Internal Agile coaches
  2. Consistent practices and processes across teams
  3. Implementation of a common tool across teams
  4. External Agile consultants or trainers
  5. Executive sponsorship

The above tips all appear to be common sense items – bring a consistent way of working from the top down and use both external and internal guidance to support the teams in their ways of working.

The fact that these are the top recommendations, however, makes it clear that consistency and advocacy are the main areas that, in retrospect, matter the most.

Three types of coaching

It doesn’t take long, when Agilists meet, for conversations to spring up about a team they’ve met that thought they were “doing” Agile simply by sitting the courses and following the cheat sheets that they’d been left with…only to find they were still going through all the old motions and not seeing the massive performance shifts they’d anticipated. From the outside, it’s clear what needs to be done differently, that these brave businesses that have bit the bullet and started their agile journey could be getting so much more bang for their buck, despite the fact that they’re already happy with the improvements they’re experiencing. Investing in coaching and the “advocacy” element of scaling Agile combats exactly those kinds of issues – you need people in the team that know how good it can be to serve as the driving force that pushes them past a handful of isolatory scrum teams delivering things fast and small.

All of the types of coaching listed in the survey are important and will impact your teams in a variety of ways:

Internal Coaching

When scaling Agile, one of the biggest things at risk is the removal of autonomy from the team. This can happen as some of the non-endemic processes (which were often removed when the team was operating without considering scaling) begin to become part of the team’s decision making once again. Giving autonomous, flexible teams these out-of-scrum considerations can cause them to fall back into attaching themselves to business needs and priorities, undoing some of their most valuable new benefits.

Autonomy and empowerment of teams can only take hold of a team when they internally know how to use their empowerment (along with when to challenge the limits of their empowerment), when to try new approaches and when/how to decide if their current ways of working are effective. With this in mind, the application of internal coaching is clear – it’s the team’s responsibility to protect their own culture from within. This can (and should) be part of the Scrum Master’s every day role, but it is the responsibility of the whole team to be vigilant too, challenging the changes that come in to the team and coming to a consensus on how to manage them. So, as much as scrum masters, agile coaches and the fabled “pastors of fun” can monitor and make recommendations, it’s important that a team wants to protect the things they value and can police themselves communally. It’s only at this point, where the team can identify and implement their own changes and deflect wasteful or damaging changes, that they can truly be regarded as self-standing.
Internal coaching as a member of a scrum team can involve looking out for team norms, challenging the things you’re unsatisfied with and even simply turning up – a team can’t push itself without consensus and accountability from everyone involved.

External Coaching

No Agile transformation can persist in a true, continuous-improvement-minded fashion without an awareness of what’s going on in the world outside. The datum is always changing and unless there are people monitoring the new techniques, nurturing existing techniques and observing the mistakes/learnings from across the agile landscape, it’s impossible to know just how good things are, or how good they could really be. It’s one thing to adopt Agile principles and reduce the duration of your release process, but what if you learned that there were CI/CD techniques that made release durations a thing of the past and that other teams could confidently release things instantaneously…you’d want that, right?

This is a common and constant factor in Agile and it requires people that can disconnect from a specific project, even a specific business or industry and explore all of the new things that have been going on beyond the horizon. External coaching can take many forms, most commonly in the forming of “communities of practice”, the hiring of deliberately detached Agile coaches and reaching out to neighbours via events and get-togethers. What’s recommended is to cycle external coaching in and out of a team so that team can tune itself with incremental improvements (kaizen) and sequentially implement the newly learned and experimental changes as the incremental change becomes less effective (kaikaku).


Without these changes in state, teams are at risk of entrenching themselves in their own local ways of working, making it harder for scrum teams to integrate and share at scale. Look out for teams pointing out the “not-agile” aspects of other teams and ask yourself which of the teams is tunneling their agile vision or imposing their ways of working on the teams around them.

Executive Coaching

A team can only perform as well as the environment that they’re in. As such, coaching of Agile values can’t start and end with only the team(s) taking part. The line in the Agile Manifesto “Individuals and interactions over processes and tools” is often compressed down to “People over processes”, when it infact is much more about getting amazing people together, empowering them with the things that they need to be as amazing as possible, then giving them the flexibility and trust in them that amazing things will happen.

In new-to-Agile and new-to-scaling businesses, it’s not always easy for the operation to just leave teams to work without telling them what to do. The way to combat this is to get in on the highest level and inform, from the board of directors, through to the teams and out to the supporting departments so that everyone, at a minimum, has an awareness of how these teams will be working and what they can do to give them the best opportunities for success.

Executive coaching is not about telling a team what they should be doing in order to scale. When done well, it’s about giving the teams the empowerment to think for themselves and the coaching aspect comes from identifying if they’re using the empowerment as best they can. Make teams aware of the support they have and the many forms it takes, baring in mind they’ll be unable to spend a resource if they’re unaware of it. Taking this one step further, teams should feel like they’re able to test that boundary. If they’re granted a hack day to try new things, are they identifying if one day is too much or too little?

Hopefully this short piece has helped, but if you’d like to talk further about any of the above then I’d love to hear from you.

*12th Annual State of Agile Report by Collabnet. ”Which of the following have been the most valuable in helping you scale agile practices? Check all that apply.” – Multi-choice answer section included an “other, please specify” field.

Cheers, Tam.

The Dirty Dozen (Part II)


So, how do you point out when you feel the team, or part of the team isn’t on the right track? How can you test whether you’re right to point these things out?

If you take a look at the Dirty Dozen, you can quickly identify whether something is affecting the team and, more importantly, whether there’s a clear pathway to resolving it.

The Dirty Dozen

The Dirty Dozen are the most common preconditions of people ahead of a human error, so can be seen as the root cause for many accidents, incidents and errors that make it from the team into the finished product:

  1. Lack of effective communication
  2. Distraction
  3. Lack of resources
  4. Stress
  5. Complacency
  6. Lack of teamwork
  7. Pressures
  8. Lack of awareness
  9. Lack of knowledge
  10. Fatigue
  11. Lack of assertiveness (often ownership)
  12. Accepting the Norms (the “we’ve always done it that way…” effect)

With these ingrained in the mindset of the whole team, it’s possible to objectively highlight performance issues as a group without starting a witch hunt. When you want to highlight that you feel the definition of done has been watered down and the quality of work is dropping “we are becoming complacent” sends a clear message to everyone in the team about what questions need to be asked and what needs to be done much faster than “it isn’t good enough”.

1. Lack of effective communication
Awareness that everything, including no communication, is a form of communication. Find opportunities for applying communication/find means of communicating more effectively

2. Distraction
Combat external factors causing distraction/draw focus

3. Lack of resources

4. Stress
Find ways to alleviate stress/reduce complexity

5. Complacency
Reconvene/reshuffle/take regular breaks/cycle feedback more frequently

6. Lack of teamwork
Redefine ways of working/identify areas of improvement

7. Pressures
Divert pressure/re-establish pull

8. Lack of awareness
Investigate/share knowledge

9. Lack of knowledge

10. Fatigue
Reduce intensity/collaborate

11. Lack of assertiveness
Establish roles and responsibilities/request direction. “If nobody is responsible for X, we’re all responsible”

12. Accepting the Norms (The “we’ve always done it that way…” effect)
Contrast with other teams/review processes and framework

Note that each of the dirty dozen has more than one positive response that will deliver benefits to everyone (there are many more unlisted, see here.

There’s less room for debate over whether something’s working optimally when the outcome is an improvement or a confidence check, so highlighting a risk in this format allows for matters to be tackled immediately and with buy-in from the whole team.

Team Maturity

As mentioned, these techniques come from century-old, battle-hardened industries. It takes time to get to a place where, for example, a junior in a team can walk up to an architect or a more experienced software engineer and say “You look tired, do you want to take a break?” or “You’re doing that wrong, are you aware of….” but I absolutely believe it’s the way things will go, if software engineering even closely follows Mechanical, Biomedical or any other mission-critical engineering trade.

Ideally, this means bringing it into Software Engineering at a college level, if not sooner, but there are things that can be done to bring it into your current teams too.

Agile’s “people over processes” value is the beginning of this. Focus on excellence within your teams, drive out issues as a team and keep in mind how interactions between individuals are the points of failure (and improvement) not the individuals themselves.

“When a flower doesn’t bloom, you fix the environment in which it grows, not the flower…” Alexander Den Heijer.

Cheers, Tam.

The Dirty Dozen (Part I)


I’m one of Opencast’s Scrum Coaches, here, I’m writing about “The Dirty Dozen, getting your scrum teams ready for the airfield”.

My first engagements with Lean and Agile came from Aircraft Engineering, where there was an extreme focus on safety above absolutely everything else. User needs, product value and the bottom line simply had to take a back seat to ensure that the people carrying out the work left the hangar at the end of the day in the same condition that they first arrived in.

For this reason, the perspective of decision making, organizing and continuous improvement had a much more savage (but more effective) dynamic, which made adapting to an office-based environment pretty tough. It turns out that when people aren’t always in imminent danger, businesses can (and usually will) place operational requirements above the human factors that go into delivering them. It’s harder to fix the human aspects of delivering work than it is to put your head down and do the work, so when there’s work to be done, it’s a great excuse for not fixing the interactions.

Agile in software, without explicitly stating this as an intention, does take some of that human focus and human value back, but, in the spirit of kaizen, there’s always more that can be done.

Human Factors is the practice of understanding human behaviour, psychology, anatomy and basic human physiology. It’s a mandatory module in a lot of mechanical and electrical engineering studies for this reason. This is often overlooked in software and process engineering despite a lot, if not all of the same risks to performance persisting.

One of the main things that’s considered on a day to day basis, when Human Factors is part of your everyday working life is the concept of “Compos Mentis” – being able to think or act clearly or responsibly and particularly “The Dirty Dozen” – 12 key factors that can inhibit this ability, particularly when working in a team.

Compos Mentis

“Working well both individually and in a team” is a popular line in most job applications, but this can go much deeper than simply being able to pair program without snatching control of the cursor off your teammate. In Engineering, where your life is often in the hands of your co-workers, this means being open about your own abilities, monitoring your teammates for signs of stress or injury, being aware of when everybody last ate, last rested…the list goes on! It also requires everyone to be comfortable with challenging the knowledge and capability of others, quite bluntly and objectively, without either party taking offence. This is just part of the everyday mindset for everyone in a workshop, whether they’re managing the team or the workload – everybody understands why and everybody has equal footing when pointing out the next potential risk.

At first glance, it may seem like a lot of these practices wouldn’t transfer well into an office environment, or may even cause friction, but it’s a level of team maturity that everyone should strive for and find the limits to, especially when it can lead to a better outcome for everyone.

Next time, I’ll be going through that “Dirty Dozen”.

Cheers, Tam.

So you’re a Scrum Master…


So you run the events during a Sprint, but what do you actually do the rest of the time?

This question was asked recently during a Professional Scrum Master course, and also been brought up in non-agile organisations (who may claim to be agile!). I’ve also consulted now in a number of different organisations, so it does get asked, often jokingly, from time to time.

So, let’s explore this…

I thought I would put pen to paper and, in addition to the Scrum Guide guidance ‘official’ stuff we have to do and the corporate or organisation stuff we have to do, I’ve bulleted some things I think we do. I’d love to hear your thoughts though, so please feel free to comment below to add to the list or comment so I can refine.

  • So, in the blog title above it mentions we run events, but what if an event was not run – what impact would that have? It’s good to discuss/demonstrate with the team what would be the consequences/downsides if an event was not run – empirically of course – it is one of the 3 pillars after all!
  • And when you do do your events, prep them and make them awesome and valuable to make the team better each time – see my last blog about retro events! #plug
  • Living and believing the agile and scrum dream should be something we do constantly with the team, with externals to the team, and also anyone we come into contact with – don’t be afraid to show this, be excited about this, demonstrate how it adds value
  • Working with the Product Owner on reviewing and aligning the backlog, and discussing the value of the features to be added to ensure the team are also aligned and understand the value of each one, as well as supporting the PO’s Sprint Goals and making sure the team are focussed on this – make these visual
  • Encouraging a mindset which is enthusiastic, creative, collaborative and experimental
  • Ensuring you have the right team skills, resource and tools to produce your increments and achieve your Sprint Goals
  • Making your team as transparent as possible
  • Question, challenge, consider and coach individuals, the system, the processes and the organisation to ensure alignment with the scrum framework, your principles, your experience and input from the team
  • Investigating and finding out the root causes of issues or blockers – and not just looking at the top layer
  • Promoting the team and how you work to wider audiences and encouraging anyone to view our working area and boards, encouraging anyone to you for a tour or talk or to see the team work in practice
  • Making the physical area as great as possible to work in – with team identification, celebrations, great creative boards and any visuals to excite not only the team, but also any visitors to attract and excite them
  • Mindset is everything – don’t just do agile – think agile and more importantly – be An individual or organisation who is agile adds so much more value and brings so much more than an individual or organisation who just ‘does’ agile or, even worse, thinks they do agile, but don’t. Note, hHaving a daily scrum to discuss your gantt chart before your stakeholder release planning committee meeting to discuss a CR and changes to the BRD does not make you agile ;-). So, a Scrum Master must exude all these great agile qualities – and always THINK agile
  • Work tirelessly with the team to achieve the Sprint Goals collectively and collaboratively
  • Being a good listener is important; ensuring each team member has an equal voice. This should always be encouraged
  • Ensure the team are actively growing their T-Shaped profile and if not, adapt accordingly to encourage this through pairing, learning and sharing skills
  • Experiment with different WIP limits, value points, events timings, event methods and mixing up the daily scrum to find the most effective way for your team
  • Ensure stories go through the agreed team process efficiently and timely and have a nice natural flow which the full team touches. i.e. optimise the flow
  • Making sure the team are happy, supported and sheltered from outside noise and distraction and onboard new team members with the same values the team have embraced
  • Make sure stories are achievable, broken down, understandable and add value
  • Make sure the team talks and collaborates constantly and when necessary, carefully onboard new team members to avoid disruption but maximise team involvement
  • Make sure the actions from each retro are followed up and done (see my last blog!)
  • Mentor and/or collaborate with other Scrum Masters to make sure we share experiences and always, like agile, constantly inspect, adapt and improve
  • My motto is to always make sure the team are Pairing, Sharing and Caring – we live by this, its on our white board and I make sure this happens – p.s. this is not my motto – it’s a team motto. It’s not about me – I’m just a servant to the team remember!

These are, in no particular order and just some thoughts – let’s hear yours below…


Sultan Speaks IoT

Over the last few decades, smart home systems have failed to spread widely in every home and be a coherent part of our life like what smart phones have done in half this period of time. On the other hand, the latest evolution of Internet of Things (IoT) and Big Data analysis gave new insights of smart platforms that can potentially lead to the new dream of ‘smart cities’.

It is expected that the most used daily tools and objects (Things) like clothes, brushes, keys, doors, etc. will be equipped with smart chips to be transformed into IoTs for future activities. Therefore, it makes perfect sense to think of future smart homes as huge virtual networks of Things that collect and process massive amount of sensor data and not just a few number of sensors like those introduced as individual products from IBM, Samsung and Intel. In our research, we survey the state-of-the-art of basic components of smart home systems, and introduce a framework for developing adaptive and self-learning home automation systems using both IoT and Big Data analytics.

The proposed framework is to augment homes with machine-learning intelligence to automatically detect different situations, self-learn how inhabitants act and eventually react and control the home autonomously. We propose our SLASH (Self-Learning and Adaptive Smart Home) framework for designing and implementing smart home systems that are both adaptive and self-learning. Our framework suggests integrating IoT across every home with a large network connected to Big Data analyser. Such an engine that supports analysing inhabitants’ behaviours on a large-scale can enable a new type of home automation that depends on machine learning and develops on-going automation decision over time.

For example, the user turns on the entrance light when entering his home – without any change in the status of other things- then after a defined number of reoccurrences, the system will sense the user’s entrance and automatically turn on the lights. The situation is defined per each sensor status – within the home –and according to the change(s) that led to that situation. With the increase in number of situations and the complications, SLASH can learn and act to support the inhabitant’s routine life.

SLASH is different than all previous work in smart home field in the sense that it starts without any predefined configuration, but rather as a new born baby gaining experiences from different situations as it grows. SLASH framework utilizes the relatively consistent behaviour of different users, captures and stores IoT/Things sensor data, and analyses through machine learning and big data analytics how the smart home should interact with inhabitants.

The framework is described in more details in an IEEE published paper stating the different stages of data collection, manipulation and data correlation that could potentially provide people with a better experience and quality of living.

If you’re interested in learning more about this or would like to indulge in some conversation, do drop us a line!