So what is a Technical Lead anyway?

What’s the difference between a Technical Lead and other developers? It’s not just about the years of experience. Some people will never learn the skills they need to become Leads, or are more interested in becoming technical specialists in one area. Some developers will show their aptitude from the start. So what makes someone a good Lead?

It’s not necessarily about technical knowledge

Is someone a Lead because they know more Java patterns than you? Because they are know what a Monad is? Not necessarily. The Technical Lead does not need to be the developer with most experience in the technology stack you’re working with right now. A junior developer with a year’s experience may have spent that time immersed in a single JavaScript framework and have the best knowledge on the team of its peculiarities of syntax and usage.

But it can be about bringing their experience to bear…

A good Lead will be looking at things more broadly. Using the example of the JavaScript framework above, a lead will be more concerned with the following:

• How does this framework fit with the rest of the architecture?
• How do we share that developer’s experience with the rest of the team so that we eliminate the single point of failure that exists due to that key individual?
• Can we write good tests for this code?

A Lead Developer will have spent years working with different technologies and approaches. This experience can be the key to being able to know how to ask the right questions, and then to take the correct actions based on those questions.

…and applying best practice

A Technical Lead knows that they won’t be spending all of their time coding, in fact they’ll spend less time than any other developer in the team and, when they do, it will be as part of a pair or in a mob – it should be rare to see a Lead typing alone with headphones on. Instead they’ll be spending their time trying to bring best practice to the whole development team – TDD, pairing, code review, running automated tests, monitoring builds and deployments and in general ensuring that if they were to leave tomorrow then team would be in a better position than before they joined. They’ll also be spending time making sure they know what best practice is – attending developer communities, having conversations about upcoming changes on Slack and doing research on advantageous new technology.

Think of the development team as an orchestra – the Tech Lead is not the solo lead violinist, they’re the conductor. They make sure the whole team works harmoniously to produce the final result.

Characteristics of good and bad Leads

In the course of my career I’ve met a wide variety of lead developers. While they have exhibited a diverse set of personalities there are certain characteristics I have seen that can make teams successful and happy, or conversely an immensely frustrating and dysfunctional experience.

 

Bad Leads

• Think they know it all
• Don’t listen to more junior staff
• Sit and code all day
• Don’t make themselves available
• Don’t know what’s going on in their team
• Take on all the complicated tasks themselves

Good Leads

• Spend a substantial part of their day away from coding
• Pair with and mentor other developers
• Keep learning and are prepared to take advice from anyone
• Make themselves open and available
• Know what they don’t know
• Know when to delegate

Still want to be a Lead?

Not everyone wants to lead a team. Many developers become contractors because they are more interested in broadening their technical experience and want to spend as much time as possible solving technical problems. But being a Lead Developer can be immensely satisfying for those who want to have an influence on the software development process and who want to help other team members to improve their skills and experience.

The skills you learn as a Lead can help you progress in your career as well – learning the fundamentals of Software Architecture, understanding approaches to Testing, Continuous Delivery and Agile Development can lead to other roles within the industry. Make sure you stay open to new ideas, listen to your peers and remember, no matter how senior you are, you should always keep learning.

At Opencast Software we’re always looking for good Leads, alongside strong developers and automated testers. Why not get in touch via https://opencastsoftware.com/careers/ ?

Using ML to improve alerting systems

ALERTING systems are an important tool for IT support teams. These teams are often responsible for maintaining and fixing services, so they need to be informed in a timely manner of any faults in order to keep services running at peak performance.

Traditionally, alerting systems consist of simple threshold-based anomaly detection processes, where the threshold value is manually set by the team. For example, the error count for each service is calculated over rolling time periods (say, five minutes) and if this count is greater, than or equal to, the threshold value then the team is alerted.

The main benefit of this approach is it enables the support team to have a degree of control over the alerting process (e.g. adjusting the thresholds according to planned activity). However, there are a couple of drawbacks:

• The threshold is static – it is the same value every day and every time, which may not be true of user activity;
• Low thresholds – usually chosen for services with lower user activity, they tend to alert on noise, or when there is an atypical burst of activity, as opposed to symptoms of a faulty service.

We decided to test a theory that Machine Learning could circumvent these drawbacks. An innovation project set up by the team prototyped an alerting system that dynamically and automatically determines if there is a genuine fault within the services.

Fundamental to the prototype is a predictive analysis tool that, for any given rolling 15-minute period, determines if the number of errors is typical or atypical.

It achieves this using statistical formulae to benchmark the real time error count value against historic data for that same 15-minute time period. Then, if the number of errors is atypical, the prototype computes if this is or isn’t noise. It achieves this by comparing the ratio of healthy calls to error calls in this 15-minute period.

Thus the prototype only alerts on a service if both the number of errors is atypical for the time period, and the error count is not the consequence of noise. In this way, the alerting of a service is controlled by an automated, unsupervised machine learning algorithm.

To determine if machine learning can improve the alerting process, we tested the effectiveness of this prototype by comparing it to a traditional alerting system over a period of 14 days, for a single service and a single type of error.

Fortunately, this was a period where there was a lot of alerting activity on this service. The traditional service alerted on 32 separate occasions. In contrast, the prototype alerted on only four occasions (these overlapped with four of the 32 occasions when the traditional system alerted).

Clearly, the prototype has the potential to reduce the number of alerts but is it missing any genuine system faults that the traditional system is alerting on? The team found the answer to this was ‘no.’ This answer was arrived at by comparing the ratio of healthy calls to error calls for each alerting period.

In the periods alerted by the traditional system, this percentage of unhealthy to healthy was consistently less than 0.5% , with a maximum of 2.93%. In contrast, in the periods alerted by both, this percentage was 50.2% at its lowest.

In conclusion, the prototype empirically demonstrates there is the potential for machine learning to seriously improve traditional alerting systems. Although this is good news, there are many other issues to consider in order to improve the prototype further. These include collecting more suitable historical data and improving the predictive analysis model.

Let us know if you’ve had any interesting findings or how you’ve used ML to improve service performance.

Andy.

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.

Sheena.

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?

Carl.

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.
https://explore.versionone.com/state-of-agile

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
Rescope/resource

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
Learn/train

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.

Fiona Talks Women In IT

This week, we spoke to Fiona Hobbs, our Head of Technology, about the drive for more women to work in tech.

Fiona started her IT career, as many people did, by studying IT for GCSE. “I only did it because it sounded interesting” she says. “I seemed to do well and, what’s more, I found I actually enjoyed it”. After leaving school to try the world of work, she felt the need to go back to the academic route. “I decided to go to college and did Computing, Maths and Chemistry, which also went well, so I decided to go keep going with it at Uni, studying Software Engineering. From that aspect, my route in was pretty normal. I took a grad position as a developer and went from there. Looking back, on a course of around 80 people, I can only remember about 5 of those who were women, so something was already amiss.” That was back in the late 90’s and Fiona feels we see the effect of that now. “There are women in IT, but when I look around I still feel the quantity of technical roles occupied by women is low, albeit nice to see more and more women in IT management positions.”

So what does Fiona think the solution is? “I’m not sure to be honest, I don’t feel there’s a stigma attached to women in IT, in fact many of the pioneers were women, but for some reason the balance is still way too low. I see some great initiatives such as HMRC’s apprentice program which had a much healthier intake, and I’m trying to spread the word by supporting various forums including Ladies Of Code so maybe we can just make it a more visible as an option to young people making choices.”

 Fiona’s not alone in trying to promote women in tech. We’re firmly supportive of this and we work with other like minded people. And, let’s not forget that women have pioneered in tech right from the early days. Throughout the Second World War, with over ten thousand people, women made up half of the code breaking force. Grace Hopper (the person who coined the term ‘computer bug’ after physically finding a moth in her computer system) created the compiler for the first ever commercial computer and Ada Lovelace is considered the world’s first ever computer programmer in 1840.

Last year, Fiona encountered Dame Stephanie Shirley at Dynamo conference. Dame Stephanie founded the revolutionary software company Freelance Programmers in 1962. Fiona found her story fascinating, although the challenges for equality in that era were somewhat different to today.

So, any final words of advice from Fiona to young women (or indeed, any young person) looking to get into tech? “It’s really no different to any other career. Just do what you want to do” she says. “Try it and see if you enjoy it. It’s a rewarding career with many great opportunities in the North East. Younger people can attend code clubs or maker parties, those a little older can come along to various forums or any of the free coding classes that are available. Get involved with the community and hackathons. Being a developer is a great career in itself, but it also opens up the doors for so many other career paths in IT.”

If you enjoyed this article and would like to see more like this, we would love to hear your thoughts.

An Interview With Mike O’Brien

Image: The Chronicle

As the year is drawing to a close, we decided to pick Mike O’Brien’s brain, founder of Opencast Software to find out the answers to some burning, important questions that have been raised over the course of the year.

Mike’s background and knowledge of the industry means that he is always on the pulse, offering intelligent insight, striving to always move forward and help shape the digital industry towards a much better, more intelligent and practical environment.

What are your thoughts on the digital switch for the NHS? How do you think it will change the NHS for the better?

It’s important for Government to use more digital services, but it must ensure that they are really well thought through, executed and delivered in a way that makes our lives more straightforward. All parts of Government need to be more efficient and in light of an aging population with longer life expectancy, the NHS needs to make its budgets go further. Technology certainly isn’t the only answer to saving money or making it go further, but if executed well, it can make a huge impact.

This month, the media spoke of billions of pounds of fraud within the NHS. Technology can certainly be used to tackle issues that would have taken armies of investigators in the past.

Any visit to a GP or a hospital immediately reveals integration issues with many disparate modern and legacy systems. As a patient, you can see issues with record keeping, exchange of data and accuracy of data. The reasons for this are well documented, but there’s no reason for this to just be accepted. Different thinking is needed and a move away from legacy thinking in terms of procurement of technology services is required.

So, back to the question – we need the NHS to be more digital and efficient, but we need to be careful how we do this and make sure that as a service it makes the life of a patient easier and more painless.

 How do you think digital transformation will affect our next generation?

 It’s a good question. It should make the next generation’s lives a lot easier. It will certainly mean they are even more dependent on technology than we are and hence it needs to be fit for purpose, secure and resilient. There’s no point in having a digital society if the infrastructure and the tools that support it aren’t up to scratch. 

What about your concerns, do you have any for the industry?

On the digital front, that we ensure the right end to end experiences are built. There are so many terrible examples right now where companies are basically giving all of their problems, internal complexity and admin to their customers. That’s not really a transformation in my mind.

Every business needs to make sure it really values its investment in technology and that it’s an integral part of business today, not just a cost centre that has to be tolerated.

What would you recommend to people starting out in this industry?

I’d say that it’s not easy. There’s a lot to learn. I’d recommend studying an excellent IT course at university that definitely has an industrial placement element. I recall that’s where you learn what the industry is all about. I’d also recommend creating a network of mentors that can help you learn the best practice in software development along with ideas on how to develop your career. There are so many different roles in the industry that are mind-bendingly complicated. I think it’s super important to have a network of experienced people to talk to in order to figure out where you should go next…

 Where do you see the world of Tech in 5 years? Will it have evolved much?

Wow. who knows? If I knew, I’d be working in a Private Equity firm!

But seriously, I think we will have more stable and well-built systems and applications as we will depend on them more and more. I’m sure we will see many old ideas resurrected as new which so often happens in our industry. Some industries will be well on the way being totally transformed like the motor industry. I really hope than utilities and telcos will improve their use of technology as they seem to be hugely lagging behind retail for example. The use of technology in the home in a more integrated fashion will make huge leaps forward.

I certainly look forward to not having to remember hundreds of log-in ID’s and passwords, or having to read electricity and water meters!

Mike believes in being results-focused, working in an Agile way. He likes to involve clients, ensuring that progress is clear and that any changes can be made rapidly. This reflects wholeheartedly on the ethos of Opencast. To find out more about what we do, you can visit our website here, http://opencastsoftware.com/ . Alternatively, you can call us at 0191 276 5656

 

 

 

 

Is A CSM Better Than A PSM?

This week, an interesting conversation was sparked when asking one of our Scrum Masters about his role and background in the industry. Rich spoke about PSM and CSM and what the positives were from acquiring these qualifications.

What exactly are positives of acquiring a CSM then?

A CSM, otherwise known as a Certified Scrum Master, is a foundation level certification and often provided by the company that you work for. It requires two full days at a training course to soak up a wealth of Scrum knowledge. From this, you then have six months to complete your exam with a 67% pass rate (with room to research and adjust any mistakes that have been made). After completion of this course and the exam, you will become a Certified Scrum Master.

CSM is currently much more widely recognized than Professional Scrum Master (PSM), and although it isn’t entirely necessary to have a qualification to apply as a Scrum Master, being certified as a CSM is advantageous when applying for a job role.

Agilescrummastertraining.com stated that “There are over 220,000 Certified Scrum Masters so the program has certainly been successful and has also helped promote the role of Agile as a viable methodology to use with software development projects.”

As CSM is much more commercialized, it will often carry more weight than a PSM. However, obtaining a PSM is becoming much more highly regarded as more people start to gain this certificate.

Why is this?

As the two day CSM is massively popular and absolutely anybody can attend the course with a 67% pass rate, it somewhat devalues the qualification as it is so easily accessible. In contrast, acquiring PSM appears to shine a light on how much more of an advanced level scrum master you are.

Unlike a CSM, A PSM gives you the option of attending a two-day course which does not require you to go to if you feel confident enough with your existing knowledge, A PSM permits you to take an assessment straight away through Scrum.org.

While PSM shows that you have a consistent terminology and approach to Scrum, it also requires you to obtain more knowledge on the role of a Scrum Master and while it is actually more difficult to pass, it provides a wealth of useful and relevant information.

Let’s talk about cost, too. With PSM costing just £150 and CSM priced well over a grand, cost certainly sways a percentage to PSM.

Finally, as the PSM certification becomes more popular, it now appears to be an attractive addition to your CV when applying for a job. Not only does it show that you have answered a number of difficult questions in a short period of time, but it shows that you have a passion for the role and an inquisitiveness to know more.

Regardless, Passion Is Still Crucial

It is important to understand that whatever certificate you end up achieving, you must be passionate about the Scrum Master role and have a clear understanding of, and passion for, Scrum. While CSM and PSM can increase your longevity by opening some doors, and they do say something about your commitment to the role, you need to mix in the right circles to share ideas and to learn new techniques.

There’s a world of great agile and Scrum forums and meet-ups. Get out there and join in!

What do you think of the PSM and CSM? Do you have both of these? Or none? We would love to hear your thoughts.