Science and Software

Lately I’ve been thinking more about the approaches and methodologies we use to develop software. With the introduction of terms such as TDD (Test Driven Development), ATDD (Acceptance Test Driven Development), BDD (Behaviour Driven Development), Specification by Example, User Stories, User Journeys, etc, etc, it’s easy to see why teams may be struggling with understanding and using these approaches. The introduction of these terms can sometimes see people getting hung up on definitions and forgetting that these approaches all have one thing in common. The intent is to build a common understanding between team members and stakeholders of different disciplines and knowledge or skill levels. All of the above approaches have a purpose and if understood and implemented well can be of real benefit to a team.

Overarching these approaches, we also have the two software methodology juggernauts of Agile and Waterfall. Agile is often seen as the new kid on the block and Waterfall as an outdated relic of the past but these views can also just be a common perception. Agile has, as people will tell you, ‘been around since the 70’s’ (depending on who you talk to) and Waterfall is still an approach being used today with success. I’ve worked on software under both of these methodologies along with hybrids of ‘Watergile’, ‘Water-scrum-fall’ and other such terms. I’ve seen a good percentage of time that should be spent developing software spent on clarifying definitions of terminology. At times, this can feel a little bit dogmatic. Jared Spool studied the habits of highly effective teams and noted that those who were more effective favoured tricks and techniques over methodology and dogma. In his transcript of ‘Anatomy of a design decision‘ he uses the analogy of a recipe as an artefact of a process not something that is exclusively needed or required to cook.

decision-making
Anatomy of a design decision – Jared Spool

 

Thinking about the things I’ve experienced and researched, I kept coming back to a process (or method) I learnt in school and one that has been around for hundreds of years, the scientific method. Regardless of the approaches, tools, techniques, tips or mindsets used in software development, the scientific method can be applied to the software development life cycle (SDLC) as an aid to understand the purpose of each stage. I’m not using explicit definitions of known SDLC models, more phases I’ve seen teams go through (or strive to go through) during product and feature delivery. I aim to be methodology agnostic.

 

Research1. OBSERVATION | RESEARCH

Before starting any project we need to know ‘What problem are we trying to solve’ and ‘Who are we solving it for’. Once we know the answers to these questions, we are then able to observe and collect information about the problem or our intended users. Our research can include things such as data analysis, market or competitor research, customer feedback or user interviews. At this stage it’s important to make sure we have both quantitative and qualitative data as well as using multiple sources to help negate the impact of bias and assumption. If we collect information from multiple sources we can make better hypotheses. At this stage we may also observe that our initial thoughts about the problem or user needs to be modified for greater impact or success.

 

2.  HYPOTHESIS | DESIGNHypothesis

If we have a balanced mix of research, observation and information, it puts us in a really good place to make a hypothesis about what we’re building and how to build it. This can be thought of as design. Making a hypothesis about software is thinking about ‘If I change X, then I expect Y to happen’. X is the visible change, and Y is the consequence of that change. For example, ‘If I change this link to a button, then I expect more users to interact with it’. From this point, I then have something to measure in order to know how successful that change has been. Design could be thought of as the visual representation of my hypothesis whether that be UI, code, architecture or infrastructure.

 

Experiment3. EXPERIMENT | BUILD & TEST

During the experimentation phase, we start to build and test the change we are intending to make. Testing also allows us to modify our build as we discover more information about the change that we didn’t know before. We may also choose to build more than one experiment if we are wanting to measure the success of an A/B test.  This phase is not to be underestimated in terms of the amount of information it can provide us and should also be considered dynamic, rather than static. The more rigorous and defined our observation (research) and hypothesis (design), the clearer the purpose of the experiment (building and testing) should be.

 

Analysis4. ANALYSIS | MEASURE SUCCESS

After the development or product team has done all their hard work, it’s then time for the push to production. It’s at this point, most teams stop and move onto the next thing with the only measure of success being that the code has made it into a production environment and is alive. But what about our hypothesis? We now need to see if what we thought would happen, happened or if we need to make further changes. Measuring the success of a change is critical to knowing what to do next and also provides us with more information about what went well and where we went wrong. This analysis of what happens when we put our software in front of either part of or our entire user base can not only provide us information about what to do in the immediate future but can also gives us insight into what to focus on longer term.

 

Conclusion5. CONCLUSION | ITERATE

By this stage we have a lot of information and because of our initial observation, hypothesis, experimentation and analysis, the conclusion about what to do next should be relatively clear. Do we need to perform any modifications or are further experiments required? Were we successful enough to leave this area of focus for now and move onto another one?  Like any good life cycle, once we have reached our conclusion it’s time to start on the next iteration armed with more information and insights than we had before.

By treating software development in a more scientific way I find it easier to understand both what needs to be done and why.

Science Based SDLC
The scientific method in software development – Stephanie Wilson

 

Approaches to Leadership

I recently went to a meetup as part of the Wellington Leadership group on the topic of ‘Learning to Lead’. During this meetup we talked about the following leadership styles, listed in order of effectiveness in bringing about positive change:

  • Visionary
  • Coaching
  • Affiliative
  • Democratic
  • Pace Setter
  • Commander

This got me thinking about leadership styles and how this can sometimes be reflected in where someone is on their own personal journey. This order of effectiveness could also be seen as something of a maturity model for personal growth and leadership. Before I get started into each style, I think it’s important to make clear that each style has attributes and traits that could make it effective in one situation but could equally make it ineffective in a different one. The ability to change the approach to suit the context is also key to this maturity model and that requires an additional understanding of the environment around us.

The Commander

This style of leadership is directive and is very task orientated. You might recognise a commander by their focus on achieving the task or goal at the expense of everything else e.g. people’s feelings, emotions or time. While useful in situations where action and a clear directive is critical to short term success, this approach can also be seen as overbearing and may alienate people due to its absence of empathy.

When people first step into a leadership position, this approach can easily become a default style as it aligns with the cultural norm of what being a manager is, telling people what to do.

As organisations and people mature, we begin to appreciate that there are different ways to get buy in other than having to use the ‘big stick’, authority or title.

The Pace Setter

When someone works hard and produces results, it’s natural for other managers to want to replicate this in other people. One way of doing this is to promote the pace setter so that they can build a team just like them. This style will encourage others to work extra hours, chase aggressive deadlines, work over lunch and commit to overtime. This can be useful when important deadlines have to be reached and momentum needs to be built but can easily lead to burnout and resentment within teams, especially when personal time is expected  to be sacrificed.

The difference between the pace setter and the commander, is that the commander is more likely to tell others what to do whereas the pace setter will lead by example and create an environment where everyone else feels they have to keep up.

Not all roles or responsibilities require this urgency and it often reduces creativity within teams as thinking time is replaced with continuous action.

These two approaches, the commander and the pace setter do come with a word of warning to use with caution. While they can be effective in some situations, they should also be used as more of a seasoning rather than the main course.

The Democratic Leader

This style of leadership is not political as the name may suggest but wants to make sure everyone’s voice is heard. These leaders are usually focused on gaining a consensus and making sure that no one is left out. When situations are tense and communication is key to resolving issues, having a leader who values everyone’s thoughts equally can help to create an environment where everyone feels heard and respected.

Because this style values each person having a fair and equal say, it can also create an environment where there is a lack of action.

This style tends to avoid decision making in isolation or without counsel and as a result of this can slow down the decision making process and create a bottleneck by preventing actions. Having an awareness of the bigger picture and understanding when it is time to ‘think’ and when it is time to ‘do’ can help to keep momentum.

The Affiliative Leader

The affiliative leader likes to build relationships and usually has a wide reaching network. They are usually warm people who have high levels of empathy and are good at resolving conflict between people as they can help to create positive connections. This emphasis on relationship building can also mean that these types of leaders are less likely to address poor performance as they value the relationships highly and may be more cautious about putting that in jeopardy or upsetting someone.

The Democratic Leader and the Affiliative Leader are similar but do have a key difference between their focus. Where the democratic leader focuses on making sure everyone has a voice, the affiliative leader is focused on building the relationships. It is possible to be democratic without being affiliative.

The Coach

One of the two most effective leadership styles, the coach is good at asking questions. By asking questions, the coach allows others to figure things out either on their own or with guidance and creates an environments where mistakes are things to be learnt from.

The coach is also good at looking at an individual as a whole person and is usually more interested in getting to know the person first choosing to see the work/life balance as just ‘life balance’.

Coaching can be difficult to do correctly and requires a healthy amount of empathy, self awareness and a growth mindset. The individual doing the coaching must also be mature in many aspects of their own self. Coaching done wrong can come across as micro managing and people can lose trust and become defensive or cynical.

The Visionary

These are the leaders tha have a vision and know how to share it in a way that encourages others to want to take part. It is considered the most positive of the leadership styles when trying to effect change. Being a visionary requires the skills to see the bigger picture and also communicate how the individual has a vital part to play in achieving the end result. This approach can empower the individual as they can feel a part of something important and also encourages autonomy.

Having a vision is not enough for this leadership style to be effective, there must also be the maturity and ability for that person to be able to hold others accountable in a positive way. To create this, trust and support are key elements for an environment to be created where no-one wants to let another person down.

How can these styles be combined?

One of the scenarios we imagined at this meet up was that of a dysfunctional team. Our facilitator asked how we might approach a team that was experiencing conflict or dysfunction as a leader. The combination we talked through was:

  1. Be Affiliative, build the relationships first, get to know people one on one and listen to what they have to say, hear their perspective
  2. Be Democratic, once you’ve built an affiliation with each team member, create an environment of democracy where everyone’s voice can be heard. It’s important to let everyone get their perspectives on the table without arguing back, contradicting or fighting. The point at this stage is to allow everyone to be heard and feel like they’ve contributed equally.
  3. Be Visionary, now that everyone knows where they currently are, it’s important to create a vision of the future and bring people into the idea of where they could be with some changes. Remember that being visionary also means that you have the ability to hold people accountable for their actions or lack of.
  4. Be a Coach, once the vision has been agreed to and people know where they want to go it’s then time to step back, be a coach, create an environment of experimentation and ask questions so that people feel a sense of control over their direction.

I really enjoyed attending this meet up and it has given me a lot of food for thought into how I can apply different styles at different times as well as being aware of what I’m currently doing and where I have gaps.

Leading without authority

At the recent WeTest 2016 conference (http://www.wetest.co.nz/), I had the opportunity to talk about leading without authority. Many companies are ditching the more traditional, hierarchical team structure in favour of autonomous, flat structures where big sticks of authority no longer exist. This can be a dramatic change for a lot of people in positions of leadership or management. Where previously people often did things because they were told to, in this new structure teams are empowered to say ‘no’ and think for themselves.

Leading without authority can be a massive hurdle for all of us, especially if we’ve never really had to think about who we are as leaders, because our titles gave us everything we needed. I had come from a place where I was familiar with telling people what to do rather than listening to what people needed. Still being a leader but having all the authority taken away was a very steep learning curve for me. Having spent the past 15 years in all types of leadership positions, I wanted to share some of the myths I had busted along the way.

Myth: People are born <leaders>, <successful>, <lucky>

Some of the time we can look at people who have ‘gotten ahead’ of us in some way and think that they don’t deserve it, that they may have gotten lucky in some way. It’s all too easy to sit back and feel sorry for ourselves, thinking that success isn’t something that will happen to us. I’ve been fortunate to have met a lot of successful people in all types of disciplines and they all have something in common. They’ve all worked for it. I feel it’s important to make a distinction here in that I’m referring to the people that are respected in their fields as people in a community as well as an organisation.

When we’re introduced to people who have already achieved success, we’re often only seeing the tip of the iceberg. What we haven’t seen is the hours of dedication, training, self reflection, learning and growing that person has been doing for years before. I can guarantee that they’ve had a few failures of their own but they made the choice to keep trying and move forward. It’s also important to recognise that these people do these things for themselves, not for other people.

People who perform well, usually do so because they have a supportive environment which allows them the time to work at getting better.

They also have the right tools, resources and opportunities to continue moving forward. It’s important to keep this in mind when building teams by asking ourselves if we’re creating the right environment for people to grow and improve. Change the environment and the people will also change.  

Myth: To be a leader, I have to know more and do more than everyone else

Like many people I’ve suffered from imposter syndrome. The thought that I was going to be found out in some way, that I didn’t know as much as people thought I knew. In my early 20’s I was given advice from an older colleague, ‘Once you accept that you’ll never know everything and that it’s ok, you’ll be much happier’. Turns out they were right. Being able to say ‘I don’t know but let’s find out’ is rather empowering. This is why we work in teams. To be able to share knowledge and collectively come to better decisions together.

A lot of my time spent in a position of leadership is listening and asking questions. Sometimes people just need a sounding board or a way to gain a different perspective of the issue or problem at hand. The other side of this is that if I know everything and do everything then I don’t give others the opportunity to learn and to grow. I am looking after myself at the expense of other people’s development.

Myth: Extroverts make the best leaders

Over the past few years there has been a shift towards classifying people as being either Introverted or Extroverted. On the face of it, we tend to classify people who speak up at meetings or at conferences, organise events, are good at networking and considered fun and loud as extroverts. Looking into this deeper, it appears this is just another way for us to classify or stereotype people. I believe that everyone is an individual and there are things that every person brings to what they are doing regardless of being introverted, extroverted or ambiverted.

No personality type makes a leader better or worse, instead we should be looking for the skills, qualities, values and behaviours a person exhibits when identifying leaders.

Human’s have an innate ability to do this. Leaders are the people we follow regardless of title. However, when it comes to job descriptions, we sometimes forget this and hire for an ‘outgoing, energetic, fun, enthusiastic person’ to lead our teams. These qualities, while inherently positive, are not always the things that make leaders great.  

Myth: If I fix all the problems people will respect me

This is a thought I believed for quite a while until I had the realisation that I needed to respect myself and my time first. I’ve worked in many offices where 10 hour days were expected and out of hours phone calls or email demanded an immediate response. I once got out of bed at 11 o’clock at night to head down to the office and check something for a senior. Talking about this to other people, I began to realise that this wasn’t healthy behaviour and that I wasn’t doing it because I cared, I did it because I was scared. Reflecting on this event, there was no reason why he couldn’t do it himself, or it could have waited until the following day.

Something happens when you become the person that fixes all the problems. You become the person that fixes all the problems. More and more often, people will continue to push boundaries and ask more of you until something breaks. The biggest lesson I learnt was to say ‘no’ and that I needed to respect myself first.

Myth: The team should do things my way

This is something I see people do quite often after a promotion or joining a new team and I am guilty of it myself. After being in a position where I was unable to make decisions and action my ideas, the excitement of being in a new role where I could make my mark was intoxicating. When joining a new team, I’ve since found the opposite to be more useful. Instead of jumping in, changing things and making a statement, it is better to relax, listen to others, gain trust and then help create an environment where people feel inspired to change.

When someone takes charge and makes decisions in isolation, teams can become apathetic, feeling as though their contribution or opinion isn’t valued.

Coming to the realisation that I am one person with my own thoughts, biases and fears, I can only do so much. Clones of myself really isn’t the best solution to anything. Utilising the creativity of the team by allowing people to do things their own way even if that includes making a mistake will foster a more harmonious team environment. Creating an environment where people feel safe to ask for help and share ideas so the team isn’t limited by their leader starts with giving trust and support to the team.  

Myth: If I had a different <title>, <team>, <workplace> things would be better

When things get hard, it’s easy to pack it all in and walk away. Unfortunately, if we walk away for the wrong reasons and don’t do the work to identify our own contribution to the situation, we can take our problems with us. It can be hard to be honest with ourselves, especially if we have been unkind or difficult in a situation when we had a choice to be kind and compassionate.

There are definitely reasons to want a new title, team or workplace like seeking a new challenge or opportunity to grow. I’ve rarely had success when I’ve made a change to get away from something. If stressful situations that are eerily familiar keep presenting themselves, the best thing to do is reflect and look at what was a common factor. Self reflection is not an easy thing to do and most people avoid it, choosing to deflect or blame something else outside of their control but it is the most valuable tool in my tool box. Being aware of my own contribution to an outcome, both positive and negative, allows me the space to grow and change.

Over the coming years, I’m sure other myths will be busted and I will learn new things about who I am as a person and a leader. I expect that I will change, evolve and grow but for now, my own truths about leadership are:

“It’s not about me”  

“Lead with empathy”

Creating a Team Experience

When helping to create and deliver software, the user experience (UX) is at the core of my daily activities. It helps guide my questioning and decision making while helping to identify the value a product will bring when it’s being used.

I recently had the opportunity to speak at UXNZ 2016 (http://www.uxnewzealand.com/) on the topic of applying the things I’ve learnt in UX to teams. I believe that the people behind the software, the creators, designers and analysts, are more interesting and more complex than what they produce.

“Great teams that are respectful to each other and work in a safe and supportive environment are more capable of building great things.”

Personas

Like most things, my story starts with the people. In UX, we use Personas to help create empathy and connect with who will be using our product. There is a trap that we can fall into when we start to classify people and that is the stereotype. In our workplaces, a lot of us have a title, something that helps others identify what our role is or what we are responsible for. When a group of people have the same title, it can be easy to assume that all of those people are alike. We assume that the people with the same title must all be the same because we can make sense of that. In short, it’s easier to think this way.

When we do this, comments like ‘Developers don’t like change’ or ‘Testers like breaking things’ or ‘Product Owners only care about deadlines’ start to be heard. This reinforces stereotypes and we lose the identity, skill and unique experience that the individuals in our teams bring. I don’t work with anyone called ‘Developer’ or ‘Tester’, there are people with names that do those types of activities and they should be recognised as the individuals they are. I like to think that addressing people by their titles is a way in which we distance ourselves from unkind remarks because we’re not frustrated with the person, we’re frustrated with the role that person plays. Unfortunately, in reality, the person being talked about can feel attacked, boxed in and restricted by their title or role. We give persona’s a name because it helps us to connect.

Prototypes

The creation of prototypes enables us to gather feedback without the need to be production ready. Having something we can interact with makes it easier to identify any usability gaps and helps develop a clearer understanding of the vision for the product.

Words only ever give us part of the picture and words can conjure up different images for different people based on their own experience or knowledge in a particular area. If I ask you to think of a vegetable, because that’s a broad category, it’s likely that we are both thinking of different vegetables. While your mental prototype might produce a carrot, mine could produce a cucumber because that was something I encountered earlier in the day. We are both thinking of a vegetable and are both technically correct but we have still failed to have a shared understanding of the same vegetable.

Being explicit in our communication by using pictures as well as clarifying words, a shared understanding is easier to reach.

When we are being implicit, gaps and ambiguity can creep in. We tend to jump to our own conclusions and understanding based on many of our own biases and beliefs that we hold. If unsure about the shared understanding of a word or idea, don’t be shy to ask ‘What does that mean to you?’.

Measuring Success

In more recent times, improvements through iterations has become critical to a product’s success. Many companies have the ability to release code to production ‘when ready’ and users can have immediate access to those updates. When we first start to measure success, there are a lot of unknowns and sometimes a few nasty surprises when we find out we’re not doing quite as well as we thought we were. The natural reaction to something we don’t want to see is to make it go away. I call this the ‘box factor’. When opening a present on christmas morning we are usually either pleased because the gift in the box meets our expectations or we are disappointed because it doesn’t. One of these gifts will be opened while the other will probably remain in the closed box, left to gather dust.

When measuring success, it’s important to be transparent and accepting of both favourable and unfavourable possibilities.

At all times we expect the outcome to indicate either success or that there is still some more work to be done, that improvements are required. This approach means that there are no nasty surprises hiding in the box because we have been transparent about the possible outcomes. Reducing the impact of the surprise of an unfavourable outcome allows us to respond from a more measured and less reactive place.

Empathy

Underpinning everything we do should be empathy, an understanding for our fellow humans. Empathy is the ability to connect with another person by understanding their point of view and recognising emotional responses. During my time in product development, I’ve picked up on three regularly said anti-empathic statements:

“At least they can…”

“There’s a workaround for…”

“Don’t worry, it’s just an edge case”

Hearing any of these in a review or product meeting immediately raises red flags for me and makes me re look at the solution in front of us. It’s a great indicator that there is still more work to be done. These statements show that we have failed to understand not only our customer and their user goals, but also that throughout development, the team has failed to communicate or understand a shared vision. Creating gaps in the product gives users the space to become frustrated or to experience an unhandled error. We have failed to map out their entire journey and have left metaphorical rivers and no bridge to cross them with.

By finding new ways to connect with the people around us in our work places, we can help create environments that foster innovation and products people love to build and use.