Accelerating my career – taking next steps with Sopra Steria

I’m a Junior PMO Analyst in Belfast, and I’ve recently joined the Sopra Steria Graduate Programme. Previously, I was a graduate project manager with Hewlett Packard Enterprise working on a range of hardware and software infrastructure projects. I am really looking forward to learning and working with the Regional Government team in Belfast and this short blog outlines my experiences to date in my new role.

The beginning: Edinburgh

Monday 4th July 2016 finally arrived – a date to remember for me and 32 other graduates beginning their career with Sopra Steria in various streams including Project Management, Java, Testing, Business Analysis, UI, SAS and GIS.

The induction was a great start to joining the company. ‘Day One’ allowed us to gain an in-depth overview of our new company – which markets we are active in, the services and solutions we provide and highlighted the opportunities for us to develop within the company. But, more importantly, it allowed us to get to know our future colleagues on a personal level as these will be who we’ll work alongside for years to come.

There was a social element too – and it was great to have an opportunity to get to know new colleagues in a more relaxed environment, as well as to talk informally to various managers away from the office.

There was a real focus on enabling us as new starters to meet a range of current staff and previous graduates. I learned a lot from asking questions about their roles and the clients that they are working with – a great benefit as they were able to give examples of real-world problems that Sopra Steria solve. During this on-boarding week, we also attended numerous instructor-led courses such as Agile Methodologies, Testing and Corporate Structure – a great foundation to understand more about the way Sopra Steria works and its approach to client engagement. Towards the end of the week, everyone received an overview of their next eight weeks in terms of scheduled training. Mine is a mix of on-the-job learning and understanding the core project management fundamentals taught within the Association of Project Management Professionals study guide.

As we said goodbye to our new colleagues and friends and I realised that I had successfully completed my first working week as an employee of Sopra Steria!

Next step: a warm Belfast welcome

As with all new starters, we returned to our contractual offices for our second week of work. For me that’s Belfast and the office is located right in the city centre and a 5-minute walk from the train station. The first few days focused on getting to know my new Belfast colleagues and more about our business in Northern Ireland. As I was being introduced I thought “I am never going to be able to remember everyone’s name!” But thankfully, it’s only taken me five weeks to overcome this. The Belfast office is home to around 80 people, but there are quite a few based on client sites so I am still getting to know new people who only occasionally work in the office.

When I was in Edinburgh during the on-boarding week I learned that the Belfast office and staff had the reputation for a sweet tooth and that any time they visited there were always cakes, buns and biscuits on offer. I found this very much the case! In the short spell I have been in the Belfast office we buy buns and cakes to celebrate pretty much anything – whether it’s a promotion, leaving party or someone’s birthday and just in case we are running short on these events there is a monthly bake-off between members of staff for bragging rights in the office. There have been rumours of a graduate bake-off happening in the near future, but I see myself eating cakes rather than making them!

As I continued to find my feet within the project management team I was gradually given an overview of each regional government client we work with and invited to attend meetings regarding upcoming projects which gave a realistic view of the projects I would be getting involved in. These face-to-face meetings are a great benefit as they allow me to see where various departments and teams within Sopra Steria fit and come together to complete projects, they are also a good way to meet the key decision-makers from a customer perspective and introduce yourself.

Everyone has been very friendly, helpful and welcoming. I’ve really valued the many offers of support from across the team and guidance to help build my new career. I’ve had some key pieces of advice:

  1. make the most of any opportunity that presents itself
  2. be responsible for driving my own career
  3. don’t be afraid to contribute by sharing ideas or thoughts on promoting or enhancing Sopra Steria. It’s great to know that at such an early stage in my career and being so new into the business that my opinion counts.

I’ve been assigned work on two different local government projects and I’m really looking forward to getting involved and understanding these accounts in more detail. Project Management is very much a learning through experience stream, reading books and attending courses is beneficial – but you really learn by doing.

I’m also really impressed with Sopra Steria’s policy on developing and enhancing employees’ talents by encouraging attendance at workshops and training courses to attain professional certification. I’m attending a 3-day Project Management course in mid-September and I am looking forward to meeting up with the other project management new starters from other organisations, while enhancing my knowledge and skills in this field.

My first six weeks at Sopra Steria have flown by – it only seems like yesterday I was travelling to Edinburgh for my induction. In this time, I’ve really settled into my new surroundings and role and am extremely excited for the future – on a personal level for continuing to develop my project management skills and for Sopra Steria as a company continuing to work on innovative and exciting solutions for our clients.


If you, or someone you know, has graduated recently and looking for exciting opportunities, why not take a look at this year’s Graduate Recruitment programme?

50 by 50 – what I learned about goal setting

When I turned forty, I decided I wanted to visit all fifty States of America by the time I was fifty and at the end of last year, I achieved the goal when I touched down in Honolulu, twenty-seven days before I hit my half-century.

Reflecting on the experiences of the last ten years, I find I have learned some valuable lessons about goal-setting that are equally useful in a professional environment.

Here are my top seven tips.

  1. If you put a deadline on something, you are far more likely to achieve it – it’s human nature to respond to the challenge
  2. Enjoy the process of getting there – be mindful of how the journey feels and have fun getting there
  3. It’s easier to achieve a goal if you have support from those around you – find colleagues whose aspirations match yours who will help and support you along the way
  4. However challenging a goal is, you will find a way to make it happen if you really want it – the human brain is capable of amazing innovation if you give it the chance
  5. Know the difference between challenging and impossible – if you’re five foot one, setting a goal to be six foot will only work if you’re thirteen years old and still growing. Believe me, it doesn’t work if you’re over twenty-one
  6. Recognise whether your deadline is immovable or flexible but don’t make a deadline so flexible that it ceases to be a true deadline – my birthday was not going to change but slipping the deadline when I finish my next novel is possible (though it does upset my publisher)
  7. Achieving a goal is like stepping up onto the next rung of the ladder – it gives you a better view but you know there are more rungs if you want the vista to be even more spectacular

I urge you all to set goals with deadlines, both at home and at work. You’ll be amazed at what you can achieve if you give yourself a challenge.

What do you think? Leave a reply below or contact me by email.

Scaling Agile the Spotify way

The first book that I recommend anyone read about Agile is “Scrum and XP from the Trenches” by Henrik Kniberg.

Kniberg has a relaxed, informal and straight-forward way of explaining how to do Scrum, which leaves you in no doubt that the author has actually been a Scrum Master himself.

So naturally, when I heard that Kniberg was working at Spotify and was experimenting with some ideas to scale Agile beyond the team level, I was very interested in hearing what he had to say.

(Image courtesy of Spotify)

Squad

The squad is the central unit of Spotify’s scaled Agile approach. Squads are multi-functional, self-organising teams that focus on a particular aspect product.

Tribes

Tribes are collections of squads which share a focus on a certain product area. They meet regularly to showcase what each of the squads within the tribe is doing – both product work and the result of hack days (see below).

Chapters

Chapters are groups which are formed across squads made up of people with similar skillsets (e.g. web developers, testers, designers, UI developers). Each chapter has a senior member who, as well as being a member of one of the squads, acts as line manager to all the other members of that chapter.

Guilds

Guilds may have membership across more than one tribe and are not necessarily restricted to one subject area. Examples of guilds given by Kniberg are web guilds – which may include web developers, designers and testers and an Agile coaches guild.

The non-incidentals

Squads, tribes, chapters and guilds might be the most obvious features of the Spotify approach to scaling Agile. But some of the others aspects of the scaled Agile set up – which might seem incidental – may well be the most important.

Tribes sit together and have good facilities

In Spotify, squads all sit together, and wherever possible, squads in the same tribe are together in the same building. The squads have control over their surroundings. They have kitchens and breakout rooms and most of the walls have whiteboards on them.

Hack days

Each squad takes one day in ten as a “hack day”. The squads themselves can decide whether they take these singly or group them together to have a whole week. The purpose of this time is to give members of the squads the opportunity to learn about new technologies and communicate them to other members of the squad. It is also an opportunity for innovation.

The release team supports the Squads

Rather than having a separate release team which handles the release of software, the goal of the release team is to allow the development teams to release their own software.

What about architects?

The architecture of Spotify is service-oriented, with over a hundred systems making up the whole site. Each service has a system owner, and the most important systems have a developer/devops pair as system owner.

The System Owner is not a bottleneck or ivory tower architect. He does not personally have to make all decisions, or write all code, or do all releases. He is typically a squad member or chapter lead who has other day-to-day responsibilities in addition to the system ownership.

What about product owners?

There is a product owner associated with each squad. As Kniberg says:

“The PO is the ‘entrepreneur’ or ‘product champion’, focusing on delivering a great product.”

Although this isn’t discussed explicitly in the articles on Spotify that I’ve read, it can be imagined that the product owners themselves would be organised into a chapter – with their own chapter lead.

What is your experience in scaling Agile? Leave a reply below, or contact me by email.

How’s our driving? Software development using Empirical Process Control

Empirical [Adjective]

  1. Pertaining to or based on experience.
  2. Pertaining to, derived from, or testable by observations made using the physical senses or using instruments which extend the senses.
  3. (philosophy of science) Verifiable by means of scientific experimentation.

(definition taken from en.wiktionary.org)

In engineering there are two kinds of process control. Defined process control deals with processes which are repeatable and fully understood in detail. Empirical process control deals with processes which are either not fully understood or are naturally very variable.

One of the key insights of an Agile approach to software development is that building software is complex and unpredictable business and so it is best handled using empirical process control.

So what is Empirical Process Control?

To achieve empirical process control you need three things: transparency, inspection and adaptation.

Transparency

In order to be able to control a complex process, you need transparency – you need to be able to see what’s going on.

Driving a car is a complex control process. When you’re driving you need to be able to see through the windscreen.

Inspection

When you’re controlling a complex process, like driving a car, it’s not enough to be able see what’s going on.  You have to actually look.  You can have a nice clear windscreen but if you’re not looking out of it, if you’re not paying attention to what’s going on, then you’re still not going to have a very effective control mechanism in your car.

Adaptation

You need to able to see out of the windscreen (transparency), you need to actually look out of the windscreen, but then you also need to modify what you do in relation to what you see.  See an obstacle in front? Slow down.  See an empty road? Speed up.  See a sharp bend? Slow down and turn the steering wheel.

When you talk about driving in this way, it’s obvious how the pillars of empirical process control – transparency, inspection and adaptation – apply. But how are they achieved in software development?

Let’s take a look at how empirical process control is realised in one of the most popular Agile frameworks: Scrum.

Transparency and inspection: stand-ups, showcases and retrospectives

The basis of transparency in Scrum is the ‘stand-up’. This is short meeting of the team every day. People involved in the project say what they’re going to do today and what they did yesterday. They also highlight any problems which are preventing them from doing what they intend to do.

In Scrum there is a role of product owner.  The product owner acts as a single representative for the organisation that wants the software being developed by the development team. At the end of each sprint (a short, fixed period of time for which work is planned, typically two weeks) there’s a meeting called the ‘showcase’ entirely for the benefit of the product owner. In the showcase the team demonstrates working software that its developed in the recent sprint. The showcase makes transparent to the product owner, how the team is progressing.

At the end of each sprint the team runs a ‘retrospective’ where they ask themselves, what went well, what didn’t go so well. They come up with ideas for things they can try to improve the team’s performance. In terms of empirical process, the team is inspecting their performance and another way to think about this is that at the end of each sprint, the team members asks themselves and their passenger – “how’s our driving?”

Adaptation: making changes in response to what you see

Planning in Scrum happens not just once, but frequently: at the beginning of each sprint. This means the product owner can adapt what the team is going to do having looked at working software. If the software is right, the team can carry on going in that direction. If there’s a problem, the product owner can modify what the team should do next. By running retrospectives and acting on their findings, the team is also adapting.

What are your thoughts? Leave a reply below or contact me by email.

Four reasons why Scrum is so popular

A 2013 survey by the company Version 1 showed that over 50 percent of all software development projects which are being managed using an Agile method are using Scrum. A further 15 percent or so are using either a “Scrum Hybrid” or “Scrumban” (a Scrum Hybrid).  This means that around two thirds (65 percent) of all the Agile projects that were taking place in 2013 were using Scrum. In the 2014 survey, this figure had crept up to 72 percent.

Why is Scrum so popular? Many of the other methods (DSMD, XP, Kanban) seem appealing and strong claims can be found for their success.  So why, in reality, is one method dominating? Here’s why I think Scrum is so popular.

Reason #1 – Scrum has a role dedicated to making Scrum work

The main purpose of the ScrumMaster is to facilitate the Scrum process. Actually, the ScrumMaster has two main purposes, the second being to remove impediments to progress that are identified by the team.  But the best way to identify those impediments is to facilitate the Scrum process.

Reason #2 – Scrum tells you what to do

Scrum isn’t an analysis, Scrum is a practice, or rather a set of practices. You too can start doing Scrum right now.

The most popular practice is the “daily Scrum” – or “stand-up”. This is a short meeting where everyone in the team says what they did yesterday, what they’re doing today, and, crucially, what’s stopping them – their impediments. This is one of the main ways the ScrumMaster identifies impediments. And then it’s his or her job to get them removed.

It really is that easy to get started, but to do Scrum more completely, the team needs to plan work in short, fixed periods of time (referred to as “Sprints”). They reflect at the end of each Sprint, how well they did, and what they would change (in a meeting called a ‘retrospective’). Finally, the team demonstrates working software to a representative of the customer.

Reason #3 – Scrum explicitly involves the customer

In Scrum the interests of the customer are represented by the Product Owner (PO). The PO agrees with the team at the beginning of each sprint which work should be done in that sprint. At the end of the sprint, the PO reviews the resulting working software and provides feedback. If things have changed since the beginning of the last sprint (priorities, understanding, technology, politics…) these can be incorporated into what’s planned for the next sprint.

Reason #4 – That’s it

There are lots of other techniques that you can use with Scrum – user stories, continuous integration, burn-down charts, burn-up charts, estimation of tasks in hours, complexity points, etc. But NONE of these are required.

Simplicity and clarity make it easy for teams to get started using Scrum. And, in my opinion, that’s why it’s the most popular Agile method, by far.

Mastering Scrum (rather than calling yourself a ScrumMaster) is a much more difficult task, but the only way to get there is to have that first stand-up.

What is your experience in Mastering Scrum? Leave a reply below, or contact me by email.

 

 

Five things I learned by teaching a training course “from the back of the room”

Our Agile Foundation Certificate training course is delivered using a “back of the room” approach. Almost all teaching points are taught using activities, discussions and self-authored presentations. We don’t use Powerpoint, we don’t use a screen projector. We do use internet searches, two-minute talks, Lego, balloons (with faces on them), Jenga blocks and origami.

Here’s a few things I’ve learned from delivering the course a dozen times:

  1. BOTR (“back of the room”) really works. Lugging a suitcase of Lego and Jenga up the stairs on the Tube I sometimes think it would be better to just talk to a slide deck. But the feedback that we get for our course is almost entirely positive. People seem to like it. And our pass rate is currently ninety-five percent, so they also remember and understand what they’ve learned.
  2. Showing is better than telling (especially for skeptics). We explore Agile techniques using physical activities and we encourage our delegates to research various Agile methodologies online and come back, not only with praise, but also with criticism (‘one star’ Amazon reviews of a method’s textbook are often a good place to look). This approach seems to work particularly well with people who are skeptical or unconvinced about whether an Agile approach will work for them, or for their project, or ever.
  3. People want to hear about real Agile projects. When we’re not delivering Agile training, our “day job” is working on Agile projects, maybe as ScrumMasters, maybe as Agile coaches. People really want to hear about this real-world experience. It’s a distinct advantage of using Agile practitioners to deliver the course.
  4. People take games very seriously. Even though the tasks that we set people in the training aren’t really important, people get totally absorbed. And that’s a good thing. We can use games in the training room to show important ideas in a safe (sometimes called a “safe-to-fail” environment). But it also means that if you’ve got any complex points to communicate – you should do them before you get out the Lego.
  5. Once you’ve tried BOTR – it’s hard to imagine doing it any other way. We’re now looking to develop other training courses, workshops and executive briefings using a back of the room approach. We know Agile and iterative approaches work. So when we do develop something new, we try it out at every step with real users, incorporating their feedback as we go.

If you’d like to be involved in that process – or you’d like to know more about attending our “Agile Foundation Course” please get in touch.

Softening the big bang

Change is good! Poorly communicated change is bad…

How often have you been in a situation where a business change has been forced upon you, has been presented as a fait accompli? How did it make you feel? Included? Receptive? Positive? Ready to run with it?

Probably not.

By its nature a digital transformation project will have an impact on a lot of people, processes and technology. So how do we communicate change in a way that feels less of a “sucker punch”? Some of the terminology we use doesn’t necessarily help. Look again at the first sentence of this paragraph where I use the word impact.

impact

noun

1. the striking of one thing against another; forceful contact; collision:

The impact of the colliding cars broke the windshield.

Do we want to break the people, processes or technology? Erm, no. We talk of “big bang” implementations. That phrase also raises stress levels. Just because a change needs to be implemented in a short timescale doesn’t mean that it will be stressful, out of control, badly planned, a failure.

Planning change is important. Communicating change is paramount to success

So what techniques can we use to manage the successful communication and buy-in needed for a programme of work to be understood, well received and, dare I say it, applauded?

Don’t be afraid to share

With many modern development projects taking advantage of alternative methods of delivery – for example Agile, which encourages open communication, collaboration and working towards the “common goal” – those teams working well together is key to the successful delivery of the project or product. However, it is equally important to share the knowledge, successes and, potentially, failures to a wider business and technical community.

Early and frequent communication can be used to generate a “buzz” around the delivery simply by showing/informing those that will be affected by the change how progress is being made and how their working life will be improved by the transformation. I’d even go as far as to suggest that some employees will be excited by the difference it may make to their customer’s lives: for example, introducing a mobile case management solution to a social worker that reduces the time needed to update notes while offering a more secure way of carrying or accessing case information, may result in less stress about case file security and generate more time in their day to have higher quality face to face meetings with clients.

Some ideas for information sharing:

  • Expanded ‘show & tells’ – a key part of the Agile methodology is to host regular sessions where the latest features of the product are demoed to the product owner (the project’s main business representative). These can be extended to include wider stakeholders or end users who may bring some valuable critique to the process
  • Programme highlight dashboard – where highlight reporting is generated for key stakeholders, is there really much additional effort needed to pick out key information that can be shared with the entire business?
  • Corporate Social Media – do you have an internal collaboration site, for example Yammer? Set up a programme-specific group and ask the team members to post updates on milestones met, challenges overcome, etc.
  • Don’t forget the traditional channels – these could include notice boards or paper flyers even if they’re simply used to point people to an online medium

Identify your digital champions

Sharing information using traditional or modern methods is one thing but identifying people that can talk about the project with knowledge and enthusiasm can be a great way to disseminate information virally through their existing networks. We call these people ‘digital champions’:

Digital champions inform and inspire people to embrace business transformation

Identification of these people can be a challenge in itself but introducing and then nurturing an open channel where the programme team encourages anyone to come and visit the team at work, ask questions or to attend the ‘show & tells’ should help draw out those who are genuinely interested. It’s important not to assume that you know who your best advocates will be. Traditional programme structures may put communications responsibility at the door of senior managers or business stakeholders. I would agree that they have their part to play, but if you’re a front line employee hearing someone enthuse about an upcoming business change, you may listen more intently to a colleague than a senior manager.

Do something!

Whatever method of communication you settle on isn’t as important as making sure you do something to educate, inform, and inspire those immediately and peripherally affected by change.

“Knowledge is power. Information is liberating. Education is the premise of progress, in every society, in every family” – Kofi Annan

Don’t we all feel better when we know more about a subject? Let me hear your thoughts by posting a comment below.