project management

Using @AnyDo for tasklist management

Trying to stay in the habit of writing, and this seemed like a quick post, so here goes; I’m not really in the habit of writing product reviews, but I’ve found this one to be useful, so I thought I’d share.

Task management is something I’ve always struggled with; I’ve tried various systems from Trello to LeanKit to Kanbanflow, and they’re hard for me to use consistently. At work, I use a homegrown SSRS report connected to our helpdesk system as a kanban board, but it’s clunky for ad-hoc requests. It takes way too many clicks to create a ticket for a simple to-do item like “set up a meeting”.

I recently got an Amazon Echo Dot (and later a Tap), and I was intrigued by the to-do list functionality; suddenly it became quite easy to jot down a quick task for either business or personal work. I just shouted out “Alexa! Add do something awesome to my to-do list”, and was immediately gratified with a task appearing in the Alexa app on my iPhone. Excellent. Except for when I was away from my desk (and my Echo Dot). I could open the Alexa app and add a task item manually, but typing seems so old school. And then I remember, Siri could do reminders too. Guess what? Integration with Any.Do.

Long story short, I can now manage nearly all of my to-do items by voice. If I have a brilliant idea while sitting at my desk, I ask Alexa to note it for me. In the car? Siri’s my friend. The beauty is that they both go to the same repository in Any Do, and I can mark them as completed as I knock them out. The only downside is that the app places them in different lists, but I can view them in one combined list (see screenshots below).

Visibility is only part of the battle; organization is equally important. One of the features that I really like about this product is the “Plan My Day” option. Basically, if you have several tasks scheduled for today, you can run a little wizard to cycle through all of them and decide if they’re really going to get done today (or not), and schedule them accordingly:

I try to keep it to 3 tasks a day; this gives me the flexibility of responding to issues as they come up, and still feeling like I’m getting somewhere. I usually add more tasks as I work, but if I finish with a clean slate (three planned + x unplanned), it’s a good day.  Lots more features to explore, including calendar integration, subtasks, and task assignments, but I try to keep it simple. I’ve been pleased with how well the voice integration works, and how natural it is to manage my to-do list now.

2017-08-11 by Professional Development SQLServerPedia Syndication The Social Web 0

5 #DevOps Books I plan to finish this year

New Year.  Resolutions, etc. 🙂

I’m notoriously bad about starting a book and never finishing it, particularly when it’s a technical book.  My goal this year is to finish the following 5 books:

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

Gene Kim is perhaps best known for his novel “The Phoenix Project”, which lays out the fundamental precepts for DevOps.  The Handbook (by Kim, Patrick Debois, John Willis, and Jez Humble) gets great reviews, and I think it does a good job of translating theory into practice.  I’ve only finished about a third of it, so I’ve still got a lot of reading left to do, but I hope to finish it soon.

Site Reliability Engineering: How Google Runs Production Systems

This one might be a little easier to cheat on my goal; I’ve already read most of it.  It’s a collection of papers written by various SRE’s within Google, and gives some great insights into their vision of applying developmental principles to operation problems.  While it could be argued that the SRE model is distinct from DevOps, there’s enough overlap that it makes sense to apply these techniques to my DevOps study.

Level Up Your Life: How to Unlock Adventure and Happiness by Becoming the Hero of Your Own Story

This one’s a bit of a stretch for most DevOps folks, but if you think of it an approach to personal continual improvements, then it makes sense why this book belongs in a DevOps collection.  I started reading this one last year, and quickly off the bandwagon.  My goal is to try and finish it by the middle of the year, and hopefully begin to apply some of the principles to my personal and professional challenges.

The Art of Capacity Planning: Scaling Web Resources in the Cloud

I heard John Willis at DevOpsDays Nashville this year, and he recommended following and reading John Allspaw (among other people); the second edition of this book is coming out this year, so I’ll probably wait till it arrives.  While I don’t do much with either web or cloud development, the principles of scaling is relevant to all kinds of applications.

Team of Teams: New Rules of Engagement for a Complex World

Damon Edwards actually recommended this book during a webcast I saw a couple of months ago, and while it’s not a technical book, it speaks to the art of transforming a large, complex organization with entrenched policies into a nimble, responsive team.  Brownfield to greenfield (with military references).
2017-01-11 by Book Reviews Professional Development SQLServerPedia Syndication 0

My Challenges with #DevOps

As I’ve alluded to in earlier posts, my career goals have transitioned away from database development and administration into DevOps implementations; it’s been a bit of a challenge for me, because I feel like a stranger in a strange land all over again. Looking at familiar problems turned on their sides isn’t for me, and my day job has some particular challenges that I need to figure out appropriate solutions for. All of that being said, I’ve enjoyed it. However, in an attempt to help me wrap my head around things, I wanted to list out the struggles I’m facing, and include my current “solutions”; these may change over time, but it’s where I’m at today.

  1. It is what it is…

One of the challenges of describing DevOps is that it’s a conglomerate of technical and cultural changes. System and software engineers can easily understand the technical components of iterative software deployment, but it’s tough to describe the organizational and procedural changes necessary to implement a rapid deployment environment (“You want the developers on pager duty? How will they administer the system?”). Most engineers have a tough time interpreting The Phoenix Project, because it’s not a technical manual; they’re used to step-by-step guides, not cultural strategies.

My solution is to describe DevOps as a philosophy, not a methodology. Philosophies have general principles that you agree to abide by (such as seeking efficiency through automation, increasing feedback, and documenting problems without blame); methodologies are strategies for implementing philosophies. What this means is that as a manager, my method of implementing DevOps is probably different than yours, and there may even be differences within the organization; the key focus should be on reducing or eliminating silos through communication. Where those silos must remain (say, in a highly regulated environment where development and operations need to be separate), workflow in each silo needs to be as transparent as possible.

  1. Brownfield change is harder than greenfield development.

Greenfield projects are new software projects or initiatives; brownfield development is a revitalization of an existing project. While each has challenges from a DevOps perspective, the technical and cultural debt that is associated with brownfield development often slows down adoption of DevOps practices. It’s tough to maintain a system while making suggestions for improvement, particularly when multiple departments are involved, all with their own goals.

For me, it all goes back to two principles: tight focus, and increased communication. As a change agent, I need to carve out time each week to focus on one small, incremental change that I can make to increase efficiencies; for example, I’m currently working on developing a standard postmortem practice for tracking issues with our business service (using this free guide from VictorOps). The point is that I may not have opportunity to make sweeping changes, but I can do a little bit at a time (and encourage my team to do so as well).

  1. Compliance is a constraint.

Working in the financial industry brings some unique challenges to implementing DevOps; while philosophically the ideal DevOps process is to build automation pipelines from development through deployment, regulatory policies are written to dictate separation and control between environments. The thicker the wall, the more likely you are to successfully pass an audit, but those walls make it tough to attain rapid development. If your developers have one set of goals (deploy new features) and your operations team have another (keep the system stable with few changes), you’ve got to figure out a way to reconcile those.

Communication is key, and that includes have a common issue tracking system to report operational issues to development as soon as they occur; I don’t manage the developers in my business unit, so I can’t set their priorities. But I can make them aware of the pain points, and the expenses associated with those struggles. I can also find ways to make our infrastructure more predictable so that developers can develop code faster, and our QA teams can automate tests with some assurance. It’s tough, but it’s my goals.

Summary

I realize that this post may not be that insightful, but I’m looking at it as an effort to keep writing and thinking about these issues. Expect more from me in the future as I continue to try and learn something new.

2016-12-12 by DevOps Professional Development SQLServerPedia Syndication 0

Where’s your slack?

I’ve been rereading the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency recently.  As I alluded to in my last post, my life has been rough for the last few months.  My nephew’s passing took the wind out of an already saggy sail; I’ve spent a great deal of time just trying to balance work, family, and life in general.  Some people turn to counselors; I turn to project management books.

The premise of the book is that change requires free time, and that free time (slack) is the natural enemy of efficiency.  This is a good thing; if you are 100% efficient, you have no room to affect change.  Zero change means zero growth.  I’ve been a proponent of slack for a while (less successfully than I’d like); it makes sense to allow people some down time to grow.  Just to be clear, slack isn’t wasted time; it’s an investment in growth.  Slack tasks include:

  • Research into interesting projects.  Lab work allows you to experience the unexpected, which gives you time to prepare for the unexpected in production
  • Building relationships. Teams are built on trust, and trust is earned through building relationships.  Teams that like each other are more likely to be successful when it comes to problem solving.
  • Shadow training.  Allow team members to work in other teams for a while; learn how the rest of the company operates.

In short, slack is necessary in order to promote growth; if you want your organization to stay ahead of it’s competition, cutting resources in the name of efficiency is sure-fire plan for losing.  The best advice for slack time is the 80/20 rule; run your team at 80% capacity, and leave 20% for slack.  In the case of emergency, slack time can be temporarily alleviated, but it’s the responsibility of management to return to normal work levels as soon as possible.

So what does this mean for me personally?  In the name of efficiency, I let slack time go.  I work a full time job, a couple of different consulting gigs, act as a chapter leader for AtlantaMDF, and am an active father.  I have no hobbies, and suck at exercise.  I love to travel, but trips are planning exercises in and of themselves.  In short, I have zero slack to deal with emergencies.  When something goes wrong and time gets compromised, I immediately feel guilty because I’ve robbed Peter to pay Paul in terms of time.  That’s not living,

I’m done with that.

Change is incremental, so I’m not planning on upsetting the apple cart just yet, but I am trying to figure out ways to make my slack time more of a recharge time.  Don’t get me wrong; I waste time.  I sit and stare at Facebook like the rest of the modern world; I binge on Netflix when new series drop.  That’s not slack, and it doesn’t recharge me. Slack is using free time to grow, to change.  My goal is to find an hour a week for growth-promoting free time.  I’ll let you know how I’m doing.

 

2016-04-11 by Blogging is FUN! Professional Development 0

Agile Perspectives: Fixed or Variable Length Iterations

Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?).  I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently.  He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.

Really, I’m doing this for my adoring fans.

Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.

Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions.  I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development.  If you have those interests, then I’m also assuming that you know what an iteration is.  If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.

The Argument for a Fixed Length Iteration

There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time.  I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door.  My reasons for supporting this model are as follows:

  1. People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend.  Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
  2. A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done).  Bite-sized code is easier to test and deploy with reduced risk.
  3. A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there.  The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.

The Argument for a Variable Length Iteration

I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable.  My friend subscribes to this model because:

  1. Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage).  Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business.  It’s like Mr. Roger’s house shoes.
  2. They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
  3. This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears.  There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.

Your Choice?

I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy.  What did I miss?  Are there other benefits to the Variable Length model that I’m missing?

2015-08-11 by Blogging is FUN! Development SQLServerPedia Syndication 5