Just discovered kibitz today via my automated whatis login script and it's amazing. According to the manpage it "allows two people to interact with one shell". Well, my team gave it a shot today when doing some pair programming and it worked out fantastically.
For example, say I want to share a terminal with user "adam" to get his advice on editing the Apache config on host "sidewinder". Once I and the user adam have a terminal session on sidwinder, I execute "kibitz adam". Then Adam sees the following on his screen:
Message from jesse@sidewinder on pts/1 at 11:00 ...
Can we talk? Run: kibitz -3330
EOF
Then Adam acknowledges by typing "kibitz -3330" in his terminal. After the acknowledgement, my side of the connection executes a new shell to share with Adam and from that point forward on we are both seeing the same terminal.
Kibitz is simple to use and it's a native utility on my Linux distributions. Just bummed it took me this long to find it. Linux keeps getting cooler and cooler...
Friday, September 4, 2015
Friday, May 1, 2015
Increasing Your Sphere of Influence
Influencing change is as much about (if not more) selling yourself as it is about selling an idea. But to be heard, people have to be listening. This is why building up your credibility within the organization is critical. Doing this takes time and dedication, but eventually you will find it is easier to influence changes in your organization.
Really what we're talking about here is building and strengthening relationships. You need to invest in relationships whenever possible, which should be all the time. Consider this as an example:
You have a conversation with a person and it goes well. You've both agreed on a problem, discussed possible solutions, and decided on primary and maybe secondary solutions. You both leave the conversation feeling like your ideas and suggestions were heard and taken into account when deciding on a solution. After this conversation, your credibility with that person probably went up, and in turn, increased your sphere of influence.
In contrast, if the conversation was mostly one sided, and you decided on the solution without much input or consideration of the other person's ideas, your credibility likely dropped with this person. Future interactions with this person may start off in a negative position based on past experience.
The rate at which you gain or lose credibility when interacting with a person depends on the significance of the conversation, the frequency of interaction with that person, and the overall feeling that the person leaves with. Never let a conversation with a person end in a negative way. If it ended poorly, try to make amends immediately. Most often this can result in a positive experience even when the initial conversation didn't go all that well.
Here are some other ways to build relationships:
The second part of influencing change is selling an idea. In my experience, I've been most successful when I've showed someone why a solution was better. Create a proof-of-concept and do a demo. Here's one of my favorite quotes about influencing change:
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” - Richard Buckminster Fuller
Another key point is to be collaborative when designing a new solution or solving a problem. People are more receptive to change if they feel they've actively been a part of it. This also provides an opportunity to look at the solution from new perspectives and identify potential issues.
When proposing change, keep in mind that you can't always win everyone over at once. Work off of the 10/80/10 rule:
Building Relationships
Really what we're talking about here is building and strengthening relationships. You need to invest in relationships whenever possible, which should be all the time. Consider this as an example:
You have a conversation with a person and it goes well. You've both agreed on a problem, discussed possible solutions, and decided on primary and maybe secondary solutions. You both leave the conversation feeling like your ideas and suggestions were heard and taken into account when deciding on a solution. After this conversation, your credibility with that person probably went up, and in turn, increased your sphere of influence.
In contrast, if the conversation was mostly one sided, and you decided on the solution without much input or consideration of the other person's ideas, your credibility likely dropped with this person. Future interactions with this person may start off in a negative position based on past experience.
The rate at which you gain or lose credibility when interacting with a person depends on the significance of the conversation, the frequency of interaction with that person, and the overall feeling that the person leaves with. Never let a conversation with a person end in a negative way. If it ended poorly, try to make amends immediately. Most often this can result in a positive experience even when the initial conversation didn't go all that well.
Here are some other ways to build relationships:
- inviting others to eat lunch with you, never miss an opportunity by eating alone
- establish a carpool, lots of time of previously unused time to bond
- offer assistance with issues that aren't your responsibility, shows you care about more than your problems
- attend/host team outings
Selling an Idea
The second part of influencing change is selling an idea. In my experience, I've been most successful when I've showed someone why a solution was better. Create a proof-of-concept and do a demo. Here's one of my favorite quotes about influencing change:
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” - Richard Buckminster Fuller
Another key point is to be collaborative when designing a new solution or solving a problem. People are more receptive to change if they feel they've actively been a part of it. This also provides an opportunity to look at the solution from new perspectives and identify potential issues.
When proposing change, keep in mind that you can't always win everyone over at once. Work off of the 10/80/10 rule:
- Influence the 10% who are innovative and receptive to change first. These people are already driving the company forward, so they are most likely open to new ideas.
- Next, with the support of the first 10% influence the middle 80%. This group of people are open to new ideas, but are also comfortable with the way things are. Show them why the new idea is better.
- After that success, there will be significant momentum and most of the remaining 10% (the naysayers) will be pulled into the fold.
Friday, April 3, 2015
How We're Crushing Technical Debt
How it all started
Year after year we'd been placing things on our yearly goals that just weren't getting done. And the list kept growing. That left us feeling like we weren't accomplishing anything at the end of the year during review time. Huge morale killer. It's not like were weren't busting our asses all year; we were always busy. We just never made time with everything else going on to work on reaching our goals. We were too busy fighting fires, or we never had the focus for what was next in line.
This year we decided to change that pattern. After a bit of trial and error, we came up with a system that has been paying dividends. With this new workflow we've paid down more technical debt in the past three months than we've done in probably the past two years.
How did we do this? We stopped trying to do everything and let some stuff fall on the floor.
But what we noticed over time, is that all we had managed to do was move our inbox workflow to KanBan (which was good for tracking), but we weren't making any real progress on knocking out the items on our backlog. We were just treading water and dealing with requests as they were coming in.
Then, late last year, a few of us started brainstorming about how to solve the backlog issue. What we decided to do is split up the team.
The Product Backlog holds our work that has not yet started. The Tech Debt team pulls all new work from the Prioritized Backlog column, which is groomed routinely by senior leaders and management. Because of this constant grooming, at any time a member of the Tech Debt team is able to go this location and pull in the next highest priority item. The Not Yet Prioritized column is normally empty, but as new requests or ideas emerge, they go here for sorting.
The Work In Progress board is used on a daily basis. New items that have been pulled from the Product Backlog board are placed into the Sprint Backlog column and then broken up by he team into individual tasks that are needed to accomplish the overall goal. Each of those tasks are taken by a team member one at a time, worked through to completion or to a blocked state, and then eventually moved to the completed column.
Every Monday, we hold a demo session with the Tech Debt team, the Systems Support team, and middle management to share what we've done. Once each item is accepted by the whole team, it's moved to the Accepted by PO column where management uses the data for reporting and then archives it.
When prioritizing items in our backlog, our default ordering routine is to sort things by the importance to the business, then importance to other teams, and lastly the importance to our team. We typically place the needs of other teams in front of our own. There are exceptions, but it's our general rule.
We have many items towards the bottom of the backlog that will likely never be completed due to the fact that they aren't big problems, and other new required work will get bumped up in front of them. That's okay. We want to work on what's most important to the whole IT system. We figure that if those items at the bottom become important enough, they will bubble up to the top.
We have also discovered psychological benefits to the new system. Before, we had so much context switching going on that our heads were spinning. Priorities were always changing and the team never had a clear feeling of what to do next. Now, since the backlog is an ordered list that is routinely groomed, there is rarely a question of what is the most important thing to do. It's liberating.
This year we decided to change that pattern. After a bit of trial and error, we came up with a system that has been paying dividends. With this new workflow we've paid down more technical debt in the past three months than we've done in probably the past two years.
How did we do this? We stopped trying to do everything and let some stuff fall on the floor.
Evolution begins
A few years back we started using KanBan. Specifically, we're using the SaaS solution from LeanKit. If you're new to KanBan, The LeanKit folks have a write up you can read here. When we adopted KanBan, we saw an instant improvement in our workflow. It was amazing. Things were getting done, you could see what everyone was working on, and you got a good sense of the team's accomplishments at the end of the week when we moved all of the completed cards into the archive. We felt like we'd made a breakthrough, and we had. Our work was organized and throughput was high.But what we noticed over time, is that all we had managed to do was move our inbox workflow to KanBan (which was good for tracking), but we weren't making any real progress on knocking out the items on our backlog. We were just treading water and dealing with requests as they were coming in.
Then, late last year, a few of us started brainstorming about how to solve the backlog issue. What we decided to do is split up the team.
The next stage
We started by splitting the team in half into two new teams: Systems Support and Tech Debt. Turns out this ratio worked for us, but if it hadn't we could have easily rebalanced the team members. The Systems Support team takes care of all of the normal day care and feeding. That's dealing with systems issues, processing new support requests, etc. The Tech Debt team pulls its work from a new KanBan board we created that contains all of our backlog items. The new workflow for the Tech Debt team blends the KanBan and Scrum methodologies into something that works for us. Here are a few screenshots to show our board layout: |
| Tech Debt Team Product Backlog Board |
 |
| Tech Debt Team Work In Progress Board |
Every Monday, we hold a demo session with the Tech Debt team, the Systems Support team, and middle management to share what we've done. Once each item is accepted by the whole team, it's moved to the Accepted by PO column where management uses the data for reporting and then archives it.
A few things we learned along the way
You might find that it's not possible to split up your team so you can get started. If that's the case, try and peel off one person first. Have that person focus on automating or delegating some of your team's work. Enough so that you can free up a second person, and then maybe another. It depends on your team's size and dynamics. Once you feel like your team is sized appropriately, get to work on knocking out the technical debt.When prioritizing items in our backlog, our default ordering routine is to sort things by the importance to the business, then importance to other teams, and lastly the importance to our team. We typically place the needs of other teams in front of our own. There are exceptions, but it's our general rule.
We have many items towards the bottom of the backlog that will likely never be completed due to the fact that they aren't big problems, and other new required work will get bumped up in front of them. That's okay. We want to work on what's most important to the whole IT system. We figure that if those items at the bottom become important enough, they will bubble up to the top.
We have also discovered psychological benefits to the new system. Before, we had so much context switching going on that our heads were spinning. Priorities were always changing and the team never had a clear feeling of what to do next. Now, since the backlog is an ordered list that is routinely groomed, there is rarely a question of what is the most important thing to do. It's liberating.
Friday, January 16, 2015
Automated F5 Configuration Backups
I've been using F5 LTMs for years, and a while back I decided to create a script to automate the configuration backup. Today I added that backup source code to my GitHub account to share the love for anyone that's interested.
Here's the overview of what it does:
1. Connect to each device, create a .ucs file, download the .ucs file and the bigip.conf file
2. Removes local .ucs files older than 30 days
3. Commits bigip.conf files to Subversion
4. Send notification email if any errors are encountered
The script has the following requirements:
* List of F5 LTM IP addresses that you want included in the backup
* SSH key-based authentication established for each target F5 device
* Email address to recieve alerts when backups fail
* SVN repository to hold the backups (this could be converted to git fairly easily)
Its been running flawlessly for me for several years now. Check it out and let me know what you think.
Here's the overview of what it does:
1. Connect to each device, create a .ucs file, download the .ucs file and the bigip.conf file
2. Removes local .ucs files older than 30 days
3. Commits bigip.conf files to Subversion
4. Send notification email if any errors are encountered
The script has the following requirements:
* List of F5 LTM IP addresses that you want included in the backup
* SSH key-based authentication established for each target F5 device
* Email address to recieve alerts when backups fail
* SVN repository to hold the backups (this could be converted to git fairly easily)
Its been running flawlessly for me for several years now. Check it out and let me know what you think.
Subscribe to:
Posts (Atom)