Working Software, Choosing Happiness: Ramblings on the Third Agile Principle

Colours of Happiness 3

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

In software development…

  • It needs to work… but…
  • It doesn’t have to be “feature complete”.  I think many people believe they’re going to get projects done faster when they “go agile” but that isn’t really the way we think about work.  Typically people have in their head that a project includes a very specific, predefined set of features (scope) that has to get done by a deadline (time) with a typically constrained budget (cost).  We think about work differently…
  • Instead, a project includes a customer-focused set of prioritized features (scope) that is considered done when it is producing real value to the customer (scope) using appropriate budget to aid with the goals of the project (cost).
  • It still needs to work.  This doesn’t have to mean that you’re going to have to hire a bunch of QA testers or that you’re going to have to implement some kind of test-driven development process… it means your engineers should be writing quality code that can be delivered frequently to the customer.

In life…

  • If we think of “working software” in life as “stuff you do that helps you improve as a human being” then delivering that stuff to yourself with a preference to a shorter timescale sounds good, yes?
  • What kind of “stuff” is this “working software”?  Well for me I’ve been trying to focus on providing the working software of healthy, real food.  I’m also focusing on choosing to be happy — the working software called optimism and resilience.
  • It also doesn’t have to be “feature complete”.  I want to start running again.  I want to take more photos.  There’s a lot I want to do that is in my personal backlog of stuff, but the important part is to start something.  It doesn’t have to be so all-or-nothing.
Advertisements

Get Better Stuff Done Faster: Why Engineers Should Work with the “Dark Side” of Tech

In NYC?  Join us for Gilt’s first tech meetup of 2015!

Hey engineers: Are you hazy on the differences between Program Managers, Business Analysts and Product Managers? Curious about why you need all these managers on your team? Think that you don’t need them at all? Cross over to “the dark side” and hear industry professionals from Gilt discuss how they successfully solve problems and get things done. Director of Program Management Justin Riservato, Director of Product Andrew Chen, Senior Business Systems Manager Susan Thomas, and Senior Program Manager Myron Miller will show you how they make Gilt engineers’ work lives easier and more fulfilling. By the end of the night, you’ll be planning to ask for more managers for your team (seriously)!

Join us for networking, learning, trading awkward Star Wars references, and post-panel Q&A’ing. Pizza and beverages will be provided! Leave your lightsabers at home, please.

I Can’t Get No Satisfaction. Ramblings on the First Agile Principle

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

In software development…

  • In order to satisfy the customer you have to truly understand what the customer needs.
    • Sometimes what a customer wants is very different than what a customer needs.
    • Keep asking “Why? Why? Why?”
    • This requires the customer to be very much engaged in what is happening.  They need to be able to express whether or not they are satisfied in real-time.
  • Early and continuous delivery of valuable software is pretty difficult to do.
    • What is “early”?  Perhaps “incremental” is more appropriate.  I’m assuming this wasn’t intended to be “early” in the traditional, calendar-time based meaning.
    • Continuous delivery == constantly changing, hopefully for the better.
    • There is no such thing as “scope creep” in Agile!
    • It is of value if it satisfies the customer, therefore the customer must determine what “valuable” means.
    • But… If delivery is continuous, when are we “done”?  Perhaps never.  Satisfaction is a tricky beast.

In life…

  • In order to be satisfied, I must actually understand what I really need to be happy.
    • What I want is not necessarily what I need.
    • Perhaps in order to get at the core of what I really need, I have to ask myself “Why do I want X?”
    • I can’t “check-out”.  In order for this to work I need to be present and engaged in my life and incrementally improving it.
  • I also need to start NOW and continuously deliver on those needs in the form of changes for the better.
    • Working software == a means by which the need is satisfied.  This could be anything from eating well, getting enough rest, to treating myself with the same kindness and respect I give my friends.
    • The key is to first really understand what the needs are — what will it take to be satisfied?
    • And finally, admitting that I am a work-in-progress.  There is no done.

What would the Jedi say?

There is no done, there is progress.
There is no scope creep, there is incremental improvement.
There is no want, there is satisfaction.

When in doubt, break out the old school risk matrix!

We have an intern with us for the winter break and her project is to organize some kind of event or meetup at our office.  She is responsible for the schedule, budget, and the scope — including the event/meetup topic.

This is her second internship with us, so she is familiar with project management concepts, roles and responsibilities.  I’ve armed her with some traditional templates to use throughout her project.  Today, I received an email from our intern.  She’s starting to doubt the topic for her event and also second guessing whether the people who need to be involved will commit to their part of the work.    I’m certain she’s also getting a lot of feedback from other members of our PMO — all trying to be helpful, but also inadvertently causing her some anxiety and panic. She was pretty much ready to scrap the existing project and start over with an outside speaker — which could be tough given the deadline for the event.

What would you do?  Here’s what I suggested:

  • Get more supporters.  I pinged some of our leads to make sure she had additional help so she didn’t feel like she had to pull this off all on her own.
  • Take the emotion out of it.  Breathe.  Don’t panic.  (This is probably the most important piece of advice…)
  • Go back to your Project Management toolkit.  In this case, our intern was dealing with a lot of fear due to all of the various risks involved such as:
    • How to I get people to want to attend this event?
    • What if no one is interested in the topic?
    • I have to rely on 3-4 people to contribute to the event, by preparing materials and also participating.  What if they can’t commit?  What happens if someone backs out?

I suggested she take another look at Risk Management including the Risk Matrix.  The act of documenting all of the possible risks to the project, assessing the probability of the risk occurring and the impact if the risk does occur.  Then once she has a handle on what her risks really are — start thinking about how she is going to handle them.  Perhaps contacting an outside speaker to come in is a great mitigation plan — but that comes with its own set of risks as well that need to be assessed and mitigated (i.e. what if the speaker is not available on your event date?  what if they require a fee?…)

While I don’t often break out “ye olde traditional project management” templates often, they are useful tools for diffusing emotional situations and dealing with project problems in a rational way.  They are also excellent learning tools for teaching people basic techniques of the various aspects of project management.

The next time you hit a snag in one of your projects perhaps one of our more old school templates can put you back on the right path.

2015 Incremental Improvement Backlog

I wonder if it’s possible to apply the principles behind the Agile Manifesto to everyday life.  Could a human being be considered both the “customer” and the “working software”?  Could I apply principles such as: simplicity, technical excellence, good design, harnessing change, and tune and adjust my behavior accordingly to become a better person?

Let’s find out.

I guess I’ll start by just getting some thoughts down on paper, then later I’ll refine these into a well-groomed backlog.

  • I want to kick-off a Whole30 in January
  • I want to stick to an 80/20 Paleo diet
  • I want to travel somewhere new that requires a passport
  • I want to get back into running 5Ks
  • I want to ride my Vespa
  • I want to speak about Agile at more conferences, meetups and events
  • I want to take more photographs and get better at photography
  • I want to cook more
  • I want to be a grateful person
  • I want to gracefully let go of things that are not meant for me
  • I want to gracefully let go of things that are no longer useful
  • I want to dress well and change up my style
  • I want to learn a new skill
  • I want to share my knowledge on Project Management methodologies more with my colleagues and my community
  • I want to strengthen my spirituality
  • I want to feel like I am constantly improving