patkua@work

The intersection of technology and leadership

Page 35 of 53

Active Passive Load Balancer Configuration for HAProxy

It took me a while to understand the help for the configuration file for HAProxy, another software load balancer that runs on a number of *nix-based systems. Here’s the resulting file that we used to successfully test an active-passive machine configuration that someone will hopefully find useful one day.

global
    log     127.0.0.1 alert 
    log     127.0.0.1 alert debug
    maxconn 4096

defaults
    log        global
    mode       http
    option     httplog
    option     dontlognull
    option     redispatch
    retries    3
    maxconn    2000
    contimeout 5000
    clitimeout 50000
    srvtimeout 50000

####################################
#
#           loadbalancer
#         10.0.16.222:8555
#           /          \
#   webServerA         webServerB
# 10.0.5.91:8181     10.0.5.92:8181
#    (active)           (passive)
#
####################################

listen webfarm 10.0.16.222:8555
    mode    http
    stats   enable
    balance roundrobin
    option  httpclose
    option  forwardfor
    option  httplog
    option  httpchk    GET /someService/isAlive             
    server  webServerA 10.0.5.91:8181 check inter 5000 downinter 500    # active node
    server  webServerB 10.0.5.92:8181 check inter 5000 backup           # passive node

Active Passive Load Balancer Configuration for Nginx

Here’s the configuration file that we ended up with testing an active passive configuration for our application using the software load balancer Nginx that I previously posted about.

worker_processes  1;
error_log  logs/error.log;
events {
    worker_connections  1024;
}

####################################
#
#          loadbalancer
#         localhost:7777
#           /          \
#   webServerA         webServerB
# localhost:8080      localhost:8181
#    (active)           (passive)
#
####################################

http {
    include               mime.types;
    default_type          application/octet-stream;
    proxy_connect_timeout 2s;
    proxy_read_timeout    2s;

    sendfile              on;
    keepalive_timeout     65;

    upstream backend {
        server 127.0.0.1:8080     fail_timeout=1s max_fails=1;    # active node
        server 127.0.0.1:8181     backup;                         # passive node
    }

    server {
        listen                   7777;
        server_name  localhost;

        location / {
            proxy_pass http://backend;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

A guide for receiving feedback

I recently gave some advice on how to give feedback effectively and was asked to give some advice about receiving feedback. My guidelines for receiving feedback are pretty much based on understanding how to give effective feedback. Ola recently also shared his experiences with this.

Before I understanding how to receive feedback, it’s useful to recap some guidelines on how to give feedback:

  • Feedback should be specific. Talk about specific observations and impact of the behaviours exhibited during those observations.
  • Believe that someone was doing what they thought was correct at the time. (Akin to the Retrospective Prime Directive)
  • Feedback should be timely. Give it early and often as you see fit.
  • Feedback should be about both strengthening confidence and improving effectiveness. It shouldn’t be about making someone feel bad about themselves.
  • The focus of feedback should be about behaviours, not perceived values or attitudes.

When you receive feedback, be prepared not to receive feedback in an ideal manner. For many different reasons, most people find it difficult to give effective feedback, often requiring plenty of practice to get almost incrementally better at it.

Gift

Photo taken the Powerhouse Museum’s Flickr Stream under the Creative Commons licence

Listen candidly
When I receive feedback, I try to listen without reacting immediately to the feedback. Some common (ineffective) feedback people give is something like, “Your code is awful”. When put that way, who isn’t going to get defensive? Even something like “You’re really great” makes it hard to understand what behaviours you should continue repeating, and what behaviours you might consider changing. It’s particularly challenging listening to other feedback if you’ve already been put on the defensive, therefore…

Clarify detail and ask for specifics
When you feel offended or shocked with the feedback, ask for what observations people made to reach that conclusion. I like to ask for what observations they made and what impact it had, as well as how they felt about it. For some people, it’s useful to help them understand that you currently feel defensive. I might say something like, “I feel like I’ve just been judged and feeling defensive. I’d like to understand what behaviours you saw had a negative impact so that I can better understand your perspective.”

Share your context with them
People often jump to the wrong conclusion because they may not have the complete picture. It’s often useful to share other motivating forces about the same observed behaviours. For example, “I joined the conversation uninvited because I feared you would never ask me for my input and I felt I had important things to contribute.”

Acknowledge and thank them for their feedback
When people give feedback, they are giving up some of their time. Some people may have overcome certain fears about giving feedback. So when you’re receiving them, ensure that you acknowledge what they are saying and thank them for their feedback. Even if you disagree with their conclusion acknowledge their contribution if you also observed the same behaviour.

Ask for feedback early and often
Giving effective feedback takes time and isn’t often at the front of people’s minds. We know that it’s easier to respond to feedback early when you have an opportunity to change something. As the person receiving feedback, it often helps to invite people to give you feedback as this alleviates the fear most people have when giving feedback, “How are you going to react?” Giving people some notice about collecting feedback also helps.

Move people away from judgements to positive action items
For some people, it will be difficult to move them away from their “evaluation” and brining them back to observed behaviours. Also, some people don’t take remember specific behaviours or impact and like to talk about their “gut feeling”. While this isn’t particularly effective, as a person receiving feedback you can still benefit by asking them, “What should I do differently?” or “What could I do to make more of the situation, or make the situation better?”

What helps you?
I’m sure there are plenty of other tips on how to receive feedback. What do you tend to focus on when receiving feedback?

Why ISO9001 standards fail

Systems and standards with good intentions are naught without proper execution. Unfortunately this is where most people get let down. People adopting agile fall into the same traps, but at least the Agile Manifesto guides people in terms of values.

Here’s how I’ve seen ISO9001 being communicated at various clients:

  • ISO9001 is a quality management system
  • A core part of ISO9001 is about control and documenting processes
  • ISO9001 is about continuous improvement

Seems harmless right? Unfortunately the way that people interpret this is as the following. ISO9001 is a quality management system. Quality management system = control and documenting processes. Control and documenting processes = continuous improvement.

Unfortunately most people never escape out of the control and documentation requirements, and the fear of failing and audit that leads to a micro-optimisation. This is why the manifesto talks about “uncovering better ways of developing software by doing it and helping others do it” and prioritising “individuals and interactions over processes and tools“.

Lack of retrospectives a smell?

On our current project, we haven’t run many retrospectives. Gasp! Anyone who knows me might be shocked to hear that.

I’ve pondered whether or not that this has been a bad thing for our project. I’m a huge advocate for using retrospectives to help encourage people to create change on their projects. I’m a huge advocate for using retrospectives to bring the team together and understand what’s going on. Fortunately I’m lucky that our team has some very strong people with probably 40% of them having true skin-in-the-game experience working on agile teams that things just get done and more importantly, things continuously improve.

I definitely believe that without all the experienced agile team members, we wouldn’t have overcome all the different and sometimes bizarre situations (ask me if you see me!) thrown our way. Do I think retrospectives still offer us some value? Yes, but probably not for the reasons that most people use it for.

It’s amazing what a bunch of energised, passionate and people with the “solve the right problem once” attitude can achieve. I’d only wish that more teams were made up of people like this more often!

Humility starts with you

One of the things most important to me when working with teams is to demonstrate constant humility. To me, you need humility in order to have courage and in order to learn. You need humility in order to have good collaboration and interactions with people.

During one of our last stand ups, I apologised in front of everyone for making the quick commit before rushing off (I had a taxi waiting). That small quick commit broke the build so I thanked the team members who fixed it for me. Everyone had a good little a laugh about it because I’m the biggest advocate for encouraging people to practice good habits (unlike what I did).

Of course I’m embarrassed for breaking the build but I’m delighted that I can say sorry in front of my team without being slapped over the wrists. It’s important to acknowledge that people make mistakes – even experienced people who have been working in this fashion for ages. It’s more important to ensure that we have a safe environment where people can make mistakes, and learn something from it, rather than being punished for it.

Come along to XP2009

At this year’s XP2009, I’m going to run the workshop, Climbing the Dreyfus ladder of Agile Practices where we’ll look at learning models (focusing on one in particular) and how to use them to help as a model for coaching and transferring skills around agile practices.

It’s going to be great fun, and contains some great material inspired by all the wonderful coaching work that Liz Keogh has been doing (we’re also hoping to get into Agile 2009).

Bring your friends, your work colleagues and anyone you think might get some benefit. I’ll be maintaining this page as we get closer to the conference.

XP2009 – Climbing the Dreyfus Ladder of Agile Practices

The results

Thanks to all the people that came along to the workshop. I had a great time and I was amazed by how many different behaviours everyone could come up with as a group. I promised to post the results, so here they all are (as a single page). I probably should migrate them to a better format, but here’s the initial step. If you have any suggestions on a better way of formatting them, please leave a comment or email me. Here are the different classifications the groups came up with for the seven different practices we could cover.

The presentation is made available through here. (PDFed as it’s smaller than the original).

continuousintegration

The Practice: Continuous Integration

Novice

  • Shutdown automated build
  • Ignores build failure
  • Manually integrates
  • Checks in code and leaves before “green”
  • “Removes feedback” from build machine
  • Checks-in, in spite of broken build

Advanced Beginner

  • Has an automated build
  • Using a check-in token

Competent

  • Checks in code relatively often
  • Runs the build locally prior to checkin

Proficient

  • Integration includes automated tests

Expert

  • Stop the line on failure
  • Nursing build machine
  • Creates automated builds
usinguserstories

Practice: Using user stories
Practice: Using User Stories

Novice

  • Uses index cards
  • Uses story template
  • User stories have some estimates
  • Trying to complete too many stories per sprint
  • Everyone on team picks a user story to implement

Advanced Beginner

  • Team members write a user story together
  • Product owner clarifies stories at meeting
  • Using storyboard
  • Estimation of user stories is relative and quick
  • Write name/title for story rather than reference number
  • Defining stories as slices of customer functionality (rather than technical chunks)
  • No one thought how to demo story
  • Talks to customer/product owner
  • Preparing user stories before whole team meeting

Competent

  • Combining stories
  • Consistent layout for story cards, “e.g. estimate in corner…”
  • User stories are delivered throughout the sprint
  • Noticing user stories epics and split
  • INVEST criteria used in evaluating stories
  • Identify technical risky stories to customer
  • Identify tasks for a story
  • Not turning down stories that need to be further investigate

Proficient

  • Splitting user stories well (small sized slices)
  • Doesn’t focus on “writing” stories
  • Estimating value on stories
  • Product owner/team regularly grooms backlog (allowing time)
  • Adding additional analysis use cases + business rules if it helps
  • Questioning user stories

Expert

  • Doesn’t need story template any more
  • Questioning if story is done
  • Using personas or stakeholder maps to look for missing stories
updatingstorywall

Practice: Updating storywall

Novice

  • Never moves items on the wall
  • Only 1 person updates the wall
  • Avoiding some items on the board
  • Command others to take a task
  • Waits for someone to tell what to do next

Advanced Beginner

  • Running stand up around the wall
  • Picking up the next task from prioritised list
  • Actively goes to wall to get next task/story

Competent

  • The team goes to the wall and updates freely during the day
  • Suggest new task to be added
  • Raises bottlenecks
  • Flagging blockers
  • Brings discussions focused on items on the wall

Proficient

  • Changing the story wall based on process changes
  • Picking up tasks from other “stages” when noticing bottlenecks
  • Adding limits to “stages” to control WIP

Expert (none listed)

participatinginretrospectives

Practice: Participating in Retrospectives
The Practice: Participating in Retrospectives

Novice

  • Shows up
  • Doesn’t know what to write on sticky notes
  • Identify what you liked/thought went good
  • Identify what did not go so well, or went poorly
  • Ignoring others
  • Respects format and timeslot
  • Yelling at others
  • Talks all the time
  • Doesn’t really care
  • Always covers up / Avoids conflict
  • Just listens
  • Not raising issues
  • Blaming problems to something outside the team’s control/influence
  • Not discussing/raising actions to actually change/improve the process

Advanced Beginner

  • Suggests ideas for team to try
  • Raises issues they are concerned about
  • Identify what went well or not so well *for everyone* (not just individual perspective)
  • Write action items
  • Discuss actions to take
  • Brainstorm, “What went less well?”
  • Brainstorm, “What went well?”
  • Doesn’t disrupt others
  • Listens to others
  • Ensures all members participate
  • Feel a need to keep all stickies “as documentation”

Competent

  • Prioritise most important action items
  • Prioritise what to discuss
  • Asks what happened to actions
  • Well prepared
  • Follows up previous meeting
  • Facilitates
  • Identify and understand the “mood” of the team
  • Records actions
  • Plays the devils’ advocate
  • Signs up for actions
  • Is honest about issues/doesn’t hide problems
  • Discusses events/issues without blame
  • Does pre-work
  • Brings calendar (to remind them of what events occurred)

Proficient

  • Dares to present crazy ideas
  • Encourages others to speak
  • Comparisons of past retrospectives
  • Shows appreciation for others
  • Follows up others with their actions
  • Offers appreciations
  • Reminds participants of ground rules when deviating
  • Comparisons of past retrospectives
  • Shows reflection on how things have progressed *over time* and shares ideas for future
  • Identifies categories of patterns
  • Moderator running/facilitating the meetings
  • Ownership of action items

Expert

  • Asks how improvements will be measured
  • Suggests retrospective on retrospective
  • Guerrilla facilitating
  • Suggests changes for retrospectives
  • Suggests improvements or new ideas for what could work in retrospectives
  • Suggest appreciative inquiry
facilitatingretrospectives

Practice: Facilitating Retrospectives
The Practice: Facilitating Retrospectives

Novice

  • Creates an agenda
  • Books appropriate room and puts appointment in the calendar
  • Just asks for good or bad

Advanced Beginner

  • Not skipping retrospectives
  • Prioritises actions
  • Introduces the prime directive / ground rules
  • Brings materials (stickies and pens)
  • Ensure last (sprint completed)?
  • Setting the stage
  • Prepares room and seating arrangement
  • Sticks to times in agenda
  • Ensure everybody understands the purpose (not blame, did as well as possible given the circumstances)

Competent

  • Uses different formats
  • Focused retrospectives
  • Checks with participants if outputs can be shared outside the team
  • Checks with participants before writing up
  • Ensures the team tries to “fix” their own problems
  • Writes flipcharts legibly and well-presented
  • Prepare some data (gather some data)
  • Introducing the speaking token
  • Follow up on last retrospective

Proficient

  • Raise issues team is avoiding
  • Explains if stepping out of facilitator role
  • People looking forward to retrospective!
  • Actions set completed
  • Varies exercises in retrospective to accommodate introvert/expert
  • Participate and facilitate

Expert

  • Prepares team to agree how actions will be measured
  • Inviting a guest facilitator
  • Facilitates big release retrospective with pre work & broader audience
  • Rotating the facilitatorship within the group
pairprogramming

Practice: Pair Programming
Novice

  • Passive when not at keyboard
  • Hogs the keyboard

Advanced Beginner

  • Active when not at the keyboard
  • Switching keyboard between people in pair

Competent

  • Mix pair programming with other practices (e.g. TDD)
  • Rotates pair
  • Pushes over keyboard to partner
  • Suggests pairing

Proficient

  • Respects the partner’s views
  • Notices partner’s mood
  • Recognises that there are different personalities
  • Answers questions

Expert

  • Questions why pair programming is not good in a particular situation
  • Knowing when *not* to do pair programming
  • Handles different skill levels
  • Handles different motivation levels
  • Adapts to different partners
agileestimation

Practice: Agile Estimation
Novice

  • Over estimating to protect
  • Too optimistic on estimates
  • Estimating using hours
  • Gaming the numbers
  • 1 person estimates alone
  • Trying to influence other’s estimates

Advanced Beginner

  • Discuss details about story

Competent

  • Encouraging re-estimation and more discussion when initial estimate range is too wide
  • Encourage discussions when members differ too much
  • Estimation as a group effort
  • Request more information from the Product Owner

Proficient

  • Raising “un-estimatable” stores to avoid assigning a random “big” size
  • Knowing when to stop estimation process
  • Bringing historical data to estimation process
  • Avoid over-discussing one time
  • Raising a need for a story to use as reference for comparison

Expert

  • Raising questions/improvements about estimation process
  • Avoid estimating too far in advance
  • Do we need estimates?

Pre workshop Details

Tell me a bit about it

Adopting agile isn’t as simple as ticking practices off a known list and moving onto the next one. It takes some effort to simply start applying a practice, and even more effort to attain a certain level of mastery. Distinguishing between apprentice-like behaviours and master-like behaviours is an important element of pushing the boundaries of a practice even more.

This workshop will introduce learning models (focusing on the Dreyfus Model of Skill Acquisition) and map behaviours we see of agile practices to the model. We will spend the majority of the session mapping behaviours we see to the stages, and discuss how people can use this model as a tool to help people progress to further levels of mastery within a particular practice.

What to expect?

Don’t worry. It’s not just going to be a lecture. 2 hours is a long time without an interactive part. I believe in lots of experiential learning and sharing with other people, so the workshop is designed with that in mind. We will have to make sure we have a common understanding of what theory before jumping in

Is it for me?

People most interested in learning, teaching and training organisations in agile methods will get a lot out of this session. This will probably include many types of coaches, people in leadership positions and any other people trying to transform an organisation into a more agile environment. I’d especially welcome people who have participated or observed agile teams as your experiences and stories will be invaluable to making this session rich and vibrant.

Wanna come along?

Everyone is welcome to participate although I’d like to keep the session to about 20 to 25 people. Contact me directly (details below) as I will give priority to those who contact me before the conference starts.

Get in touch with me

Email is best using the following address: emailpat@thekua.com. Remember that the first people to contact me will be given priority attendance if the workshop fills up. Please tell me what sort of role you are in, what you hope to get out of the session and any questions you may have. I hope that people have the right expectations before they take part.

Credits

I’d like to thank the coaches and training people in ThoughtWorks, particularly Elizabeth Keogh for the background work of this model and her continued passion for coaching.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑