12 Principles of Agile Adapted – Principle #4

This one is easy and is probably why I started this blog in the first place.

Agile Principle #4 says:

Business people ad developers must work together daily throughout the project.

When my husband and I decided that we wanted to have a baby we nicknamed the trying and all the early days stuff “Project 3.” We used that nickname a lot and sometimes we still reference it (17 years later) with smile. It has been a highly successful project with a long-lasting team.

I’m sure it will come as no surprise that I do manage my family like an agile project. I hold a stand-up with my daughter most mornings over breakfast. She doesn’t know it, but I ask her what will be happening in her day and make sure all our schedules are coordinated for rides or games, etc. On Sundays we have family dinner and we go through a list of stuff we track progress on like college visits or exams or drivers ed – sound like sprint planning to anyone else?

My interpretation of this principle then must be:

Family members must work together daily when they live in the same household.

12 Principles of Agile Adapted – Principle #3

This one will require some interpretation to make it personal, but I think I can give it a go.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

I’m not a developer so I am not delivering working software in my personal life. Certainly not with any frequency at any rate. So…after turning this around in my mind for a bit I’ve arrived at this interpretation:

Take lots of small steps towards things you want.

This is exactly how my blog was born. I wanted to do some writing on Agile and my experiences applying it to my real life. The idea of writing a book crossed my mind, but as I began exploring the idea many roadblocks jumped up at me ad suddenly it was very daunting. When I switched to thinking about a blog, I was excited and got the whole thing up and live in a few short hours. Admittedly I have not been the most robust blogger, but I continue to make progress towards my goal on a regular basis.

The small steps are easy, or easier.

12 Principles of Agile Adapted — Principle #2

Looks like I am going in order because I know that’s the kind of person I am, but in the spirit of this principle, I am still reserving the right to deviate. That being said, here’s Principle #2″

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Welcoming change and expecting is, to me, one of the keys to Agile. It was what first drew me in when I finally realized there is no perfect project plan and no perfect set of requirements.

In life change can be a lot things from the plan for the day to finding a new job to a new haircut to a welcoming a new baby. Change can be hard and also exciting. If you google it you can find a million quotes about the inevitability and the necessity of change. Accepting this and embracing it are important to keep from stagnating.

We all have our routines and our patterns and our traditions, but I see this principle as a reminder that just because “that’s the way I’ve always done it” is not a good enough reason to not try something new. Being open to small things like a different kind of book than you usually read to big things like moving to a new country bring with the them so many possibilities. I could list so many examples of small, spontaneous decisions that made a huge, positive difference in my life right along side the bigger stuff. Saying “yes” can be magical.

Of course, we all make mistakes too. We choose the wrong path in one way or another, but being open to change means being able to reverse course on those situations as well. Obviously some things are more permanent, but there are always adjustments that can be made even if it is hard to do. You can free yourself by admitting you made a bad change.

So the second principle of AgileIRL is:

Welcome change – big and small. Being open to trying something new has the possibility to make a big positive impact.

12 Principles of Agile Adapted — Principle #1

Last week I was co-leading a training with one of my new colleagues. The class was 2 parts and the first part was a refresh on Agile basics including the Agile Manifesto and the supporting 12 Principles. Although the content of the presentation deck was not new, some of the exercises were. One of the first exercises we did was having the class break up into groups and distill the 12 Principles of Agile into 3 word statements. This worked really well, but also inspired 12 blog posts for me. My plan is to interpret each principle for use IRL (in real life) and not just at work.

I’m not promising to go in order, but for the first post I thought I ought to start with the first principle.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Obviously this principle is about teams delivering value early and continuously. I’m not usually delivering “products” outside of work, but I am sharing and spending one very valuable asset — time.

I, like most adults, have a limited amount of free time so I want to get the most out of it that I can. This usually means I can’t get to every chore and I can’t do every fun thing either so I need to prioritize how I spend my time to achieve a balance between productivity and fun.

Errands and chores typically fall into 2 categories: immediate need or nice-to-have. Driving my kid to practice or buying new deodorant when I have run out is an immediate need, but cleaning out the coat closet and getting an early start on holiday shopping are nice-to-haves.

Social and leisure activity falls into similar categories: stuff you feel like you should do or stuff you really want to do. Too often I have said “yes” to something I didn’t really want to do, but felt I should, but when I do get the word “no” out of my mouth the guilt passes quickly as I enjoy more time doing what I want to do. Sometimes that means doing nothing.

So the first principle of AgileIRL is:

My highest priority is to satisfy the needs of my family and myself by ensuring that I spend my time effectively on both things I have to do and things I want to do.

Nothing Worth Having Comes Easy

Job hunting is not easy. It takes a lot of work and can be extremely frustrating. In most cases it is something that you have to work at. Despite the stories you’ve heard, jobs are probably not coming to find you. In any case, you are probably doing yourself a disservice if you don’t do some amount of research on what’s out there before deciding on your new job.

About a year ago I decided it was time. It was overdue really. I wanted to move on in my career and it was not happening for me. Just like waiting around for that new job to find you, waiting around to get promoted or advance in another way is foolish. These opportunities rarely find you, you have to seek them out.

The problem was I hadn’t looked for a job in a long time and every time I went online to look at job sites I would get lost down a rabbit hole and nothing truly productive would come of it. It was then that I realized that my show was not ready for the road. My resume was not up to par, my research on the market was non-existent and all I had was a desire for a new, different job.

And now that the ink has dried I feel like I can share how I used Agile principles to help me find an Agile job.

The first thing I did was cure the rabbit hole issue by committing myself to spending 2 hours every Sunday on my job search. This gave me both a cadence and a time box along with a commitment. Instead of just thinking about looking for a new job, I was going to actually do something about it. And I was going to try not to let it overwhelm me. I still had a full time job and a full time family. This was a major step for me and it really got the ball rolling and I noticed the difference in my willingness to say out loud to my friends and family that I was actively looking for a new job.

The next thing to do was to create my own backlog. What did I need to do to get myself ready to apply to jobs? My priority list looked like this:

  1. Research jobs that are out there that I think I want
  2. Narrow down the titles I am interested in to a manageable few
  3. Narrow down any other keywords
  4. Update my resume
  5. Choose job sites and set up my profile and searches on those sites
  6. Start submitting applications
  7. See what happens
  8. Keep trying

The research was fun and interesting and I was happy to see that there were some really interesting opportunities out there so the first few steps were pretty easy and quick. Unsurprisingly resume writing was difficult and time consuming. After several weeks I had a draft that I thought was pretty good, or at least good enough to get started. I actually used the particularly appealing job descriptions to help me craft my resume.

I started applying and at first I was getting some responses and even though they weren’t quite what I wanted I was hopeful, but the responses dried up quickly and so did my enthusiasm for phone screens/interviews for the wrong job. (At first it was really good practice though.) I was frustrated at my lack of progress. Around that time I came across one of those inspirational magnets in my local bookstore. It said:

B9C65091-B641-4904-938E-48801F7FD6AD

This is derived from the Theodore Roosevelt quote:

“Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led difficult lives and led them well.”

I bought that magnet and put it on my wall near my desk to serve as a reminder that this process was going to be worth it no matter how drawn out, painful and/or frustrating. I turned to it many times when I wanted to give up and thought of it as my goal – to get a job worth having.

I decided I had to inspect and adapt my approach since it wasn’t yielding the right results. I turned to some professional help for my resume and got some excellent advice on content and formatting as well as a decent cover letter template. I’m still not sure a cover letter ever gets read, but you usually still need one so I wanted mine to be good. This took some more time away from looking at actual job postings, but it was really worthwhile.

New resume in hand I applied for more jobs and I started getting somewhere, but still not quite where I wanted to be so I thought more about what I could do to improve my “product.” I started spending some of my time each week on my LinkedIn profile, on my profile on the job sites, and on tweaks to my resume. I added in a few more job sites, but this got really overwhelming so I trimmed it back. I also spent more time looking for companies I wanted to work for rather than just the job postings that showed up in my searches.  

Eventually I had something employers were interested in. The real interview process began. There were some false starts and some failed interviews, but each time got better and closer to what I wanted.

There is a point when you are interviewing when you just have to wait and see what someone else will decide about you. At that point I realized the best way through it was to keep looking and keep applying. You never know what is around the next corner and keeping up with it helped me to feel like I still had some control. Additionally continued response to my resume was a helpful reminder that I was wanted.

In the end I had 2 offers — both for jobs I wanted. After all the phone screens, interviews, leadership tests, etc. making that decision was the most stressful time of all, but I do believe that my process led me to a good place and although I could only accept one job, I don’t think I could have gone wrong either way.

This is a long post, but I will just summarize by saying that cadence, limiting work in progress (WIP), and continuous inspect and adapt cycles were key for me in my job search. Job hunting is NOT EASY. It takes courage and perseverance. Even so, I say, go for it.

Oh! Like Rugby!

So I have been a Scrum practitioner for many years now and sure, I was taught that it is called Scrum because of the Rugby term when the team all comes together and forms that circle and then I’ve pretty much always moved on from there because what the heck is rugby, anyway? All that has now changed for me.

This spring my incredible daughter decided that she wanted to join the rugby team. I admit, I was apprehensive. What little I’ve seen of the actual game made me nervous and confused. Haka anyone? I watched a few practices and didn’t learn much. Even the first game was just a confusing mess of girls knocking each other down, but by the 4th or 5th game it started to make sense and I even started to cheer in the right places.

I think it was the 6th game when the girls had a scrum that I asked a more knowledgeable  parent sitting next to me, “When do they have to scrum? ”  and she replied “When forward progress stops.”  And suddenly I got it. Finally.

img_0061
My daughter is in that scrum somewhere

If you already understand rugby this next part will be very boring and possible not 100% accurate and for that, I apologize. You should skip to the next paragraph.

Like American football a rugby match starts with a kick-off. From there the teams try to move the ball down the field in a series of short runs and passes. When the ball carrier is tackled, the ball is still in play and can be handed off to a teammate or can be stolen by the opposing team. Play does not stop unless there is an illegal move, the ball goes out of bounds, or someone gets hurt enough to need medical attention. In order to score, called a “try”, the ball must grounded in the opponents goal area (the end zone). Points can also be earned in a conversion, penalty, or drop goal, but lets leave that aside for now.

After the light bulb went off I thought to myself, they really should have called it “rugby!” To me the game of rugby is made up of a series of sprints. Just like in the Scrum process the team has to work together and collaborate to meet their goal — to score. Maybe more-so than in most other sports I have watched. Several short runs and passes is the most effective way to score and any player can score. Sounds a lot like User Stories and Tasks. Helping and backing up teammates when they are blocked (or tackled) is essential for success. And (among other things) the scrum in rugby is an opportunity to regroup and re-set, as is the daily stand-up, or daily scrum.

Over the course of the season I watched my daughter and her teammates go from a confusing bunch of girls on the field to a real team working together and scoring a lot. (Thanks in no small part to their amazing coach.) This is much how a Scrum team gets started. It is rocky at first. Lots of adjustments are needed, but after awhile the team finds its strengths and its flow. The rugby team, like a Scrum team, has to make on-the-fly adjustments when unexpected things happen and therefore they both cultivate and value agility.

img_0001

Why can’t we go faster?

I recently had a discussion with a Product Owner working with one of my teams. He was frustrated because a new feature that was released last week has a bug and he doesn’t want to advertise the feature until the bug is resolved. This is an established team that works in 3 week sprints and is releasing code to production at the end of every sprint. This team is also working for a global insurance company where process and regulation are part of breathing and Scrum is just starting to be accepted as a formal methodology. That’s to say that releasing code to production every 3 weeks in this environment is pretty darn fast.

The Product Owner’s question was, “Can’t we move to 2 week sprints so we can get the work out faster?” (I should also note that the team has been largely together for a long time and the Product Owner is the newest member of the team.) His feeling was that if we had shorter sprints then he wouldn’t have to wait as long to get a bug resolved. He is not happy about having to wait another 3 weeks to promote the new feature. I am not happy about it either, but I don’t think the number of weeks in the sprint is to blame. The team has been established on a 3 week cycle for a long time and nothing significant has changed to warrant making a change this drastic.

I suggested that the process is not at fault here. The issue was actually with the quality of work being turned out by the team. Testing should have been more rigorous (including his own, btw) and that would have caught the issue before it was released. He wasn’t crazy about this explanation as it did nothing to get his feature out there sooner, but I held strong to the quality problem. I said I would talk to the Scrum Master about bringing this into the next retrospective so that team would be aware that defects are being noticed and having a real affect on the product and the reliability of the team. After all, if the quality of work was better, he wouldn’t have to wait even 2 more weeks for a properly working feature. He would have it right when he expected it.

And if we  introduced a shorter sprint cycle velocity would surely suffer the pains of change.

Perhaps there are other issues we need to look at in this team as well. For example,  maybe they are just committing to too many story points? I would always rather see a team reduce their velocity in order to improve quality than rush to get a lot done and risking defects. Perhaps there was a miscommunication in test cases and something needs to be looked at there? Never underestimate the value of good test cases.  Whatever is causing the quality issue it is most important to identify the issue in the team even though it is easier to blame the process.

Agile Victory over Status Reports

Let me start by saying I hate status reports. I don’t think anyone who writes them tells the truth, but rather they are painting a picture of how they want the reader to see the project. On the flip side I don’t think anyone bothers to read them unless there is some glaring RED boxes or type. There are better ways to see the health of a project, but none-the-less, they are a necessary evil in the corporate world.

I was asked to start performing this necessary evil for a new project I am working on. The Program Manager sent around this suggested template for all the project leads to use every week.

status-report-1

This is on top of a weekly meeting where we will discuss all of these updates. Talk about traditional waterfall overkill and meaningless reporting!

After I wiped my tears I noticed that in the email the sender asked for feedback on the template. Aha! If I have to do a weekly status report why not actually report what matters. I started thinking about what would make a better template and then inspiration struck and I thought of the Daily Stand Up. The result of my inspiration was this:

status-report-2.jpg

Look familiar to anyone? Current update = what I did this past week, Focus for Next Week = what I am doing next and Risk/Blockers, of course. One simple RAG for all.

I sent the template out and all the other workstream leads liked it as well so the Program Manager agreed.  Hooray!

I consider that a victory for Agile within a waterfall project.

Sweater Weather

It is finally getting cooler here in the Northeast and therefore it is time to bring out the warm sweaters.

landscape-1479399608-fair-isle-sweaters

I love sweaters, but I hate the process of changing over and organizing my closet twice a year because it always turns into a full day project with straggling things like dry cleaner trips and Goodwill runs left hanging on for weeks.

A few weeks ago I was preparing a presentation on Kanban so I was re-reading Kanban from the Inside by Mike Burrows. Those of you familiar with Kanban know that one of the main tenets of Kanban is to limit Work-in-Progress (WIP).  The reason for this is that there is a limit to the number of things you can do simultaneously and still do them well and get to done-done. This got me thinking about my closet. My problem is that I try to do it all at once.

So, this year I decided to limit my WIP. I made a list of things I wanted to do (tasks) to get my closet organized for winter, I gave them a size (as in effort) so I could decide what I had time for, and I tackled them one-by-one over the course of a few weeks instead of losing a full, precious weekend day in my closet alone with my clothes and shoes. I mean, I love my shoes, but I prefer when we are out together. I also employed the “1 Minute Rule” which helped with things like “I’m not sure if that fits me anymore” and “Are these shoes too worn out to keep?”

I got through my list of closet (and dresser) tasks rather painlessly this way and it was done in about 2 weeks not including the Goodwill drop-off.  I wish I had tried it sooner. I was able to do as much as I had time for at a single sitting. If I had an hour I chose a bigger task, but if I found myself with 15 minutes there were a good number of small tasks on the list as well. And throughout I never felt like I “lost” any time to the job.

Kanban is the quiet cousin of Scrum, but it really deserves its own show.  I love it.

Here’s the checklist I created for this exercise:

closet