The Dirty Dozen (Part II)

667102

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)

667102

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…

667102

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…

Rich.

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!

Sultan.

Awesome Retrospectives part II by Rich

667102

Previously I talked about my enthusiasm for retrospectives and how it’s a self reflection process that, done correctly, ensues and enables the team and individuals to grow. Moving on from this I wanted to share my thoughts on running these sessions.

It’s important to plan what you, as a Scrum Master, want to achieve during the retro session and what is needed by the team at that particular time. So, ask yourself:

  • Are the team a bit flat or is an energiser needed?
  • Is there an undercurrent, so a feedback discussion (possibly through anonymous feedback) is required?
  • Is the team new, so getting to know each other is important?

It’s vital to identify what is right for the team at that particular time to maximise the value of the retro.

Now, you have decided the type of retro you want to do, think of where you are going to have the session. Please don’t have it in the same place everytime! Is it the Summer to have outside? Mix up the rooms, buy some treats and make sure everyone attends. Why wouldn’t the team want to attend if it was different, fun and awesome each and everytime?

Now, I’m not going to go into what retro activity you actually do, as you can Google these or be innovative and create your own – it’s endless. I will probably share my favourites in another blog, but once you have had decided the aim, the activity and the location, there are a few other basic rules for the Scrum Master:

  • Always encourage participation
  • Always encourage collaboration
  • Everyone should have a voice
  • Encourage sharing
  • Encourage caring
  • Encourage honesty
  • Encourage creative thinking

And always have actions (for any of the team to pick up -but get an owner in the session!). Make sure things change – we want to continuously improve and adapt – we’re agile right!

Now, to close the retro, I would always summarise the session, covering off the actions and owners. You could always end it with a one word on exit scribbled on the white board or on a Post-it note to get everyone’s feelings as we head into the next sprint. Remember, we want everyone to be enthused, engaged and excited for the next sprint don’t we?

Now, throw everything away from the retro – except the actions of course (you’re gonna write these up so you can track these), and that way you can focus on the outcomes and not problems. That’s it! Simple, right?

Before I end, just to put in a nutshell for your awesome retro:

  • Prepare well
  • Deliberately facilitate
  • Vary activities and methods – every time
  • Track actions
  • Make it fun and different
  • Listen to everyone
  • End it with positivity

Remember – this is to add value and not just to go through the motions as a Scrum Event – so don’t let it turn into that.

Don’t waste this valuable opportunity to grow as a team. Let your retro be awesome.

Rich.

Awesome Retrospectives part I by Rich

667102

Richard Haydon is one of our senior scrum masters, helping our clients deliver great digital services to their customers. We asked him for some thoughts on retrospectives and he started with a quote:

“We do not learn from experience…we learn from reflecting on experience” John Dewey

As a Scrum Master, my favourite event has got to be the Retrospective! I just love it! And it’s not just because I always make them fun through learning, it’s because I know the team will grow every time as we open up, be honest and therefore develop and flourish together as a team. That’s what’s it all about isn’t it? Working hard, but learning and having fun along the way with great colleagues who you trust.

As a team, it’s a great indication of success, and the retrospective is a great way to achieve this. So why not make it awesome – every single time?

I’ve heard from teams about previous Scrum Masters where retros have been the same every week (mad, sad, glad) 😦 and that brings tears to my eyes. In my experience this will only lead to unhappiness, boredom, habitual thinking, lack of focus and participation and – guess what – no actions.

It makes me so sad that these events could be wasted when they should be so valuable to the team – and therefore the Scrum Master.

So… why wouldn’t you want to maximise this session and make them all awesome?!

I’ll chat next time about prepping, but, before that, we go back to basics. The retro is about how we work together, not the what – it’s a reflection.

“…reflection is a self-involvement process… personal experience, feelings and cognition are intermingled in recalling past experience, resolving current difficulties, easing out uncomfortable feelings, evaluation one’s present and past performance and searching for new perspectives and new solutions.” (Yip 2006)

Till next time.

From Big Org to Opencast – Nick’s Story

667102

In this blog, we tell the story of one of our agile BAs joining Opencast, how he felt his career was at a standstill and how moving from a large, grade-based organisation to Opencast opened up new opportunities.

“After 14 years in a big organisation, moving to an SME consultancy was something that was well outside my comfort zone but on reflection, is one the best decisions I have ever made.

So where do the differences begin? Well, they start at the beginning: recruitment. Going from a long, convoluted process that takes weeks/months to one where being interviewed and offered the post inside 2 weeks was amazing. There’s no room for bureaucracy at Opencast and this is reflected how they recruit people. There’s not an endless trail of emails between post holders, applicants and the resource department. You deal with one or two people from start to finish.

So, after accepting, I began working with one of their clients where several other Opencast employees worked. I was personally introduced to everyone and was taken for lunch as a way to meet my new colleagues. With those niceties over, it was time to get to work. And this is where I saw probably the biggest difference.

From day one, Opencast trusted me as a Business Analyst. I was trusted to work effectively with the client, provide them with my expertise, knowledge and skills as a BA. I wasn’t given performance targets or work objectives to meet along with those boring (mainly pointless) monthly 1-2-1s to review my progress against targets.

They feel that as a specialist, you should know what ‘good performance’ is, regardless of your role. This approach makes you feel solely responsible for how you carry out your role and how much value you bring. This is quite an enlightening feeling after spending what must be 100s of hours over the years being told what to do to ‘get better’ at my job. If you’ve ever worked for a large, grade-based organisation, you’ll know how painful that process is. Here, I can sort out my own training for my own ambitions and I can talk when I want to.

Being made to feel welcome at Opencast is one of our biggest attributes I believe and is at the foundation……the staff are the main asset. I’ve felt this feeling of being part of a team, with Opencast t-shirts, mugs and lanyards along with various team events throughout the year. There are absolutely no heirs and graces at Opencast and everyone you speak to whether they are based with clients or in the office at Hoult’s Yard, they always greet you with a smile and genuinely pleased to see you. After all, you’re part of the Opencast family!

So, I am now one of ‘the’ BAs at Opencast, not just ‘a’ BA, I now feel I am respected by my colleagues for my skills, knowledge and experience as a Business Analyst and not by what someone who ‘thinks’ they know what a Business Analyst is/does.

Everyone else at Opencast are specialists at what they do too, they are not ‘9 to 5’ people. They strive to get better in their role and are constantly learning new practices whether that be by attending role specific seminars or community events.

And finally….

If, like me, you find yourself at a bit of a crossroads in your BA career and you’re not sure what to do, don’t think it’s the end of the road. It doesn’t matter how long you’ve been with an organisation. If you feel like you’re not getting anywhere, get out. Don’t let your current circumstances stop you from being a great BA (if that’s what you want to be). If it takes a leap of faith to join Opencast Software, then weigh up your options and go for it. After all, this is your future we’re talking about here and there’s more to life out there.”