Happy Ada Lovelace Day!

In commemoration of one of the first women in computational science, I want to celebrate the women I know who are in STEM (Science, Technology, Engineering, and Math). I thought I'd write about one woman who has inspired me, but - wonderful problem! - there are so many who have inspired through the years that I can't decide on just one.

So here's to the many women who inspire and guide me:

• my birth mom, who took computer programming while pregnant with me, and has recently jumped into engineering after a career in teaching
• my adopted mom, a nurse of amazing precision
• my engineering and mathematical sisters and sister-in-law
• my amazing niece, who has conquered accounting
• all the incredible women I've worked with - and am working with - in the IT industry
• the growing number of young women who are breaking down the STEM stereotypes and proving their awesome skills

All of you have worked hard to make a difference in your corner of the world, to challenge the status quo, and to leave your mark on the world.

Thank you, my sisters in STEM!

Agile and the Post-it® note

There used to be a joke that agile was developed by 3M to sell more Post-It® notes. And I must admit, I certainly use those little sticky pieces of paper in all sorts of agile activities: planning, retrospectives, parking lot items, take-aways….

But why?

·         Portability – allows the team to re-arrange as needed for categorization.

·         Multiple writers – who hasn’t spent time watching one person write user stories and/or tasks into Rally or TFS? ‘Nuff said.

·         All voices – everyone can write, so everyone can have a voice, even those who don’t like to talk in groups.

·         Right-sized – a 3x3 Post-It® is really all the size you need for a user story. I used to use the mini-sized ones (2x2) to write my daily list on – anything more just couldn’t get done.

·         Stickiness – well, most of the time. The notes can be transported anywhere, or even gathered up and stuck in a folder for later reference. There are many surfaces where Post-It® notes don’t work as well, but then a little painter’s tape can help!

Are there alternatives?

The “old school” way was using index cards and a bit of painter’s tape to create story and task cards. I recall using larger index cards for the stories, and matching the colors for the associated task cards. Painter’s tape, magnets or pushpins could be used to attach these cards to the appropriate walls.

One tool that I have found useful when working with distributed teams is Google Drive/Docs. This is especially useful when you’re in an environment where laptops are ALWAYS present. Everyone around that conference table has their laptop out, and can very easily add their notes to a shared Google document. The folks working remotely have equal access, without any additional steps to be heard. And it’s fun to figure out who’s the “anonymous wallaby!”

As a bit of a tangent, a cube of mini stickies and a file folder are a quick and easy way to make a personal Kanban or scrum board.

Misunderstandings, corrections, and confirmations

I just had an interesting three hours of interactions of various kinds that revolved around misunderstandings.

First off, I booked tickets for my mom to the wrong city - big gaffe. I noticed it when I printed the itinerary for her, and thanks to a well-designed web site, was able to adjust very quickly. My mom now gets a business class seat on the way out - a nice perk, even if it will cost a little more.

I also had to redo a status report - twice - to ensure that it was accurate. The people who consume the report were straightforward in identifying the needed corrections, and I was quick to respond, which in part contributed to a second revision. but the information was quick and resending doesn't take long with email.

Next, at one of my favorite lunch joints, after repeating the type of dressing I wanted, I still got the wrong one, but my second favorite, so I didn't make a big deal out of it. If it had been a bigger issue, I could've corrected it before the first drop of dressing landed on my salad.

And lastly, my clients were rather confused about a training that I'll be offering. Now admittedly "One-oh-one" sounds very much like "one-on-one," so the mistake was easy to make. Again, the issue was resolved very quickly with a recognition and correction.

How many major issues could be resolved with less pain and fanfare when caught early, and resolved in a straightforward manner, with the recognition that people - myself included! - make mistakes!?

Stories, poker, and funny money

Have you ever noticed that, along with big visible charts and frequent communications, agile teams tend to HAVE FUN?

Playfulness and creativity go hand in hand with productivity and motivation. So of course there are lots of activities within the agile world that aren’t boring, run-of-the-mill meetings and stodgy workdays. 

User stories – We’re all pretty familiar with the concept of user stories. But maybe the next time the product owner is introducing a new set of stories to the team, call the meeting “story time” and serve cookies and milk.

Planning poker – How many of you get to say that you play poker at work?! Okay, so it’s planning poker, used to estimate level of effort on deliverables, but still… I think planning meetings are more light-hearted simply because of the cards (physical or electronic).

Team and other names – I’ve been on teams named The Simpsons and NCC-1701-D. I’ve worked with teams named after cars. I’ve used colors, Simpsons character names, and extinct or near extinct animals for iteration names (who can talk about the Dodo iteration without breaking into a grin?!). And while second or third attempts to release the same code may not be fun, I can now kind of laugh about release 56.5. Then there’s the Platypus project…

 

Buy-a-Feature – Product owners can even enjoy the fun! The next time your team of product owners and/or stakeholders can’t agree which deliverable takes priority, have them play “buy a feature” with funny money – either monopoly cash or scrip you create on your computer with pictures or the CEO, CIO, and CFO in place of presidents. More information is available on Innovation Games.

Food – Sweets and fun just seem to go together. And while I know it’s important to watch caloric intake, red vines, cookies, and mini-chocolate bars will add a certain amount of levity to any gathering.  A big bunch of grapes or cuties (those little, easy-to-peel oranges) are also great options.  

How else do you have fun at work? What brings levity and helps creativity flow?

The Vision

I watched “The Hobbit” the other day with my family. I was in an agile frame of mind, and found many examples of how the travelers used agile practices in their journey. (If you haven’t read the book or seen the movie, be warned – I give away some of the story.) For example, as the dwarves clean up Bilbo’s kitchen, I could see that everyone understood their specific task, and they knew their goal so clearly that they could use irony to express it in song - “Chip the glasses and crack the plates! | Blunt the knives and bend the forks! | That's what Bilbo Baggins hates!”

Of course, the dinner scene is only a small part of the movie, and the overarching vision of the journey is certainly not to keep Bilbo’s house clean – that’s just one small goal along the way. The dwarves have a vision of returning home.

Bilbo, unfortunately, isn’t fully aware of the group’s vision when he heads out without his pocket handkerchief. Yes, he’s read the contract, he has a basic understanding of his duties, and he’s even heard the stories and the songs of the dwarves, but he doesn’t initially understand the WHY.  He finally gets it through a conversation with Fili, in the middle of the night. Bilbo has decided that he wants to return to his own home and is preparing to leave.  Then Fili explains why returning to the Lonely Mountain is important – it is the dwarves’ home. The vision finally sinks in for Bilbo. Now the hobbit also understands why it’s so important to get to the Lonely Mountain. Now he gets why this journey is so important to them. Now he becomes fully engaged in the journey, even risking his life to protect Thorin.

Even though he signed the contract, the REAL reason for the journey wasn’t clear to Bilbo until more than half-way through the movie. Bilbo needed to be told many times, and through many avenues, before the vision finally stuck – before it became reality to him. My hunch is he’ll have to be reminded again before the trilogy of movies is over.

As agilists, we must clearly and frequently express the project vision (desired state) and goals (steps to get there) to every member of the team. We may know the vision, but how well does the team understand? How well does the Product Owner understand? Is it posted somewhere? Is it discussed frequently in planning meetings, demos and retros? Oh, and do YOU really understand the vision, and the steps to get there?

My challenge to you is two-fold, depending on where your team is in relation to a project vision. If the vision isn’t identified, spend some time at the next planning meeting, with the product owner, to identify an easy-to-remember vision (for example, “Provide the customer with an easy-to-use tool to search for and buy books”). Once identified (or if it already exists), get the vision in front of the whole team as frequently and in as many different ways as you can – write it on a white board, add it to your signature block in internal emails, remind them of it in planning meetings, check frequently to ensure that it is still accurate.

Downstream WIP Limits – Another cooking analogy

I made a rather extensive Sunday brunch a while ago for the family, with a couple of new recipes that I prepared the day before– sweet rolls and a spinach and almond pie (think soufflé in a crust). Both turned out great, but in my “retrospective” after spending the day cooking, I realized I had missed something.

Both recipes had many steps, and since the rolls required quite a bit of time in the bread machine, I made the assumption that I could work on them concurrently (start the rolls in the bread machine, start the pie crust, then the filling, etc.). I goofed.

While the time that I needed to prepare both items could be handled by me, I failed to take into account that both items needed to end up in the oven – at very different temperatures.  I handled my WIP (work in progress) limit just fine, but paid no attention to the oven’s WIP limit of ONE. Everything turned out fine, but it meant that I had to delay baking the pie (the rolls took priority, since they HAD to go in the oven once they had risen sufficiently). My afternoon of baking ran well into the evening. Not that I was busy the whole time. I just had to wait on the oven.  

This story illustrates the reasons why lean processes seek  to reduce the 3 M’s – muri (overburden), muda (waste), and mura (unevenness). I experienced mura, because I had to wait on the oven’s availability, then rush to finish the job. The oven was dealing with muri, as it needed to respond to multiple requests and couldn’t. And I experienced muda, as I wasted a beautiful evening waiting on the oven, when I could’ve gone for a bike ride!

This is similar to situations in development, where the 10 developers on a team may not be paying attention to the overload of tasks placed upon the 5 QA engineers; or where the 7 development teams aren’t aware of all the tasks the app support team must do for each team. Unless everyone involved in the process is aware of where the limits (sometimes called bottlenecks) exist, you may find yourself with excess inventory (code waiting to be delivered, or a pie waiting to be baked). The 3 M’s seem to go together - unevenness in the process is a symptom of overburden on one part of the process, and both result in waste, as sections need to wait, and inventory ages.

What can be done to alleviate bottlenecks, or limits? Sometimes, re-allocating staff can help, but only briefly – this isn’t a permanent solution. When you’ve got one thing (like an oven), that just has one task (bake things), the upstream process needs to take that limit into account. When my husband offered to help, there really was nothing he could do, but wait with me. Now, if he could buy me a second oven…

Just Do It

I worked with a client once who “really wanted” to start trying agile practices; however, the manager kept delaying training until the licenses and software for the TFS scrum templates add-on had been acquired and installed.  Despite my protests, it was three months before we could start the pilot project – which only lasted two months!

Agile practices don’t expect you to start from a “perfect” position, or to follow a prescribed path. That’s kind of the point of the agile framework – it’s designed to work with multiple organizations, with a variety of cultures, experiences, issues, products … I hope you get the point. How can we pretend to identify the best starting point with all those variables? Unless we say that the best starting point is where you are now?

How many of us delay activities at home or work because the time is not yet perfect? We think we’ll need forty minutes to clean the junk drawer, and we only have twenty, so why start? We can’t create all the folders for our finances for 2013 yet, because we’re not sure if we’ll need one for the savings account we think we may close.

Here’s where Nike and agilists agree – JUST DO IT. It may not be perfect, but it won’t get done if you don’t start. You may need to make some revisions on a system because you forget the credit union account that only sends quarterly statements, but it’s okay to add that folder later – even without matching labels.

You know, there’s even a process in the agile framework to allow for this need to modify on the way – Agile Principle 12 calls for frequent reflection, with the ability to tune and adjust behavior to be more effective.

What are you waiting to start (or modify) until later? Will you really benefit by waiting? Or can you Just Do It?

Face time

As many of you are aware Yahoo!has a new policy, requiring staff to work in the office – no more telecommuting. Like many, I thought at first that this was a big step backward for the company. It didn’t make sense that a high-tech company wouldn’t allow its high-tech employees to utilize that technology to work remotely.

However, after reading the reasoning behind the policy shift, and reflecting on my own desire to be physically present at work when possible, I understood the logic. While telecommuters may be more productive and better able to balance work and home responsibilities, face-time fosters collaboration and innovation. If you want creativity and original ideas, you don’t want your staff working at home all the time. Despite all the modes of communication available, there’s something about face-to-face conversations, and chance meetings and discussions, which get the creative juices flowing. If Yahoo! wants to be a leader in innovation, this is a wise move.

Admittedly, not all development groups are able to work together physically all of the time. And not all development groups need to be fully focused on innovation and creativity. When at least 80% of our communication is provided through non-verbal channels (such as eye movement, posture, hand gestures, facial expressions), it’s easy to see why face-to-face communication is the preferred mode. The agile community feels this concept is important enough to include as a principle (“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”).  Teams will make decisions faster when they work out the issue in one room. Information flows easier when you can spin around in your chair to ask a question, or when a teammate can answer a question she overhears.

It seems possible to have the best of both worlds. The employee, their team, and the manager should be able to work out an arrangement that allows for time at home and time at the office. I recall a job where we had core hours identified (10-3), when meetings were held and people were expected to be in the office – that gave lots of time for morning and afternoon child pick-ups, dentist appointments, home repairs, etc. Expectations for being present one or two days a week may be an option as well.

Now, I find it humorous that I’m writing this the week I move to a client engagement that is fully remote. Granted, the work to be done doesn’t require a lot of creativity. The other consultant on the project and I have agreed that we should get together on a regular basis, just to make sure we communicate. Of course we can communicate by phone, email, IM, Google Hangout, Skype, etc. But without real face-time what will I miss when Scott tells me about a change in the form layout? Face-time is definitely important.

Slack Time and Connections

I had a great weekend. A lot of things happened, but not the things I'd expect.

I reconnected with a dear friend - just a chance meeting - and through our discussions came to possible solutions for three small issues that had been scuffling along the edges of my consciousness for a few months. We didn't mean to solve these problems when we started chatting. They truly just came!

This was proof to me that slack time - or down time - is incredibly important for our minds. It provides an opportunity for our powerful organic computers to process information in ways we have yet to understand, and create connections to seemingly disparate things. This wouldn't have happened if I hadn't greeted Audrey and stopped worrying about my "things to do" list. Because I was simply present, I was open to possibilities.

Chance connections, both personal and objective, can be excellent opportunities for new ideas, thoughts, dreams to form and take flight.

My take-away from this? Don't be single-focused; allow time for chance to take over. You never know where it will take you! Allow for some day-dreaming; talk about those weekend plans or experiences; walk through a museum. The background processing of your brain will kick in, and you may be pleasantly surprised!

Baby steps to BIG CHANGE

Transitioning to agile practices can be extremely difficult for an organization. It’s a BIG CHANGE.

I’ve spent many hours contemplating how to split the BIG CHANGE into smaller pieces of change, very much like the process of reducing epics into manageable user stories, and then into tasks. For example, how do you take baby steps from (original state) to (desired state)? How do you move from an environment of testers and developers who only communicate via email and bug tracking system, to a team who converse multiple times a day about what they’re working on, when it may be finished, and what’s in the way?

There have to be some small steps that can be taken from the original state to the desired state, right? What baby steps get you to the state you want? LifeHack recently posted a blog on baby steps - what baby steps work for agile transformation?

When I was first learning about agile, the IT department I was a part of was in this exact state. We rarely talked to each other. Our new manager (a change agent and expert scrum master) decided to get us started on the road to CHANGE with a small change. “Tomorrow, we’re going to try something called stand-ups. We’ll meet in my office for five minutes. Everyone will say what they worked on yesterday, what they’re going to do today, and what (if anything) is in the way. We’ll try this every day for a couple weeks, and then see how it’s going.” Hmm. Five minutes a day didn’t seem too daunting. We really didn’t talk much those first two weeks, but we started to understand the value of verbally expressing what we were working on. After the first two weeks our manager’s office got transformed into our scrum room, with our story board on one wall (the manager sat in the cube-farm with us). Our manager was quick to identify follow-up meetings (“Susan, can you and Amy work that situation out after the stand-up?” “Troy, help Clayton with the automation script.”), so we never went past 10 minutes (with a team of 6 people). This was our initiation into agile. Many people didn’t even realize it, until we had additional training a month or so later. Then the light bulbs went on. After two months, if we weren’t able to have our stand-up, many of us felt “off” the entire day.

A colleague described another example of the agile journey at a previous employer.  After being waterfall for many years, the team began its agile journey by having a dedicated “project room” where the team would do their daily stand-up, occasionally “huddle” to resolve questions and issue. After a few months, that project room became an open space work area for the team, where developers and testers regularly interacted but still had independent work areas. That environment/culture then started to include paired development (developer pairing with another developer, or developer & tester). From there the Product owners and Subject Matter Experts (SMEs) began to embed with the developer and testers; forming a team that was constantly interacting, inspecting and adapting. This journey did not happen overnight, or in a matter of months; it covered about 2 years, and matured and adapted further for years afterward.

What other small changes have you experienced that helped you – or your team – dip your toes into a BIG CHANGE? If you'd like to share, please comment, or tweet your thoughts with the tag #AgileBabySteps.

All Time isn’t Equal

If you spend two hours on submitting your time card for the week, was that time well-spent? What if you spend two hours planning your strategy and goals for the year?

We all know that our time is limited, and sometimes we struggle to understand how or where to spend that time to our best advantage.

In a great blog, Elizabeth Grace Saunders takes a riff on the “time is money” tune, this time using our automated deposits and transfers as an example.

For important projects, where time really matters (strategic planning, time with the family, etc.), schedule blocks into your week to make sure you get these done. Perhaps just as important, don’t devote too much time to those tasks that don’t provide a great return on investment (two hours for completing a time card? There may be a way to automate the process, or talk with your manager about what’s really necessary).

And yes, if you schedule it into your week, you should really DO IT! I know I struggle with getting a sufficient amount of exercise on a weekly basis, so I have multiple opportunities for working out. Each week may be different, but I will still manage to make time for at least an hour of yoga. Ah!

Back to the routine

My son flew back to college today. Yesterday, we took the Christmas tree down. As we get back  into the normal routine of a "regular" weekend, I realize that the holidays are officially over.

But sometimes, routine is useful. It's nice to know that some choices are already made. I know exactly when to set my alarm for Monday morning, because my youngest son has to be at school by 7:15. I know how much coffee to make to fill travel mugs for my husband and me, and there's no need to determine if we'll have an extra cup or two.

You see, even little decisions like "how much coffee should I make for today?" take up decision power. There's evidence that making decisions - even little ones - is taxing on a person. It takes energy to make choices. So having a routine, where choices don't have to be made, frees the mind to make more complex decisions later.

It's nice to know that I am conserving brain-power when I automatically make a piece of toast with jam for breakfast.

By the way, working resolutions into your routine help you keep them. Making the workout, or the blog-writing time, part of a daily (or weekly) routine helps those new activities become no-brainers as well.

So, hurrah for the routine!