≡ Menu

Incremental versus Iterative: The Church Analogy

Along the path towards agility inevitably one comes across the terms iterative and incremental. I have seen many cases where the terms are used interchangeably, even though the mindset behind them is pretty different. To understand how, let’s introduce Roberta and the Church Analogy.

Picture of woman holding a computer and talking

Roberta (in our analogy) is the lead pastor for a rapidly growing church. Her current congregation is usng every inch of space in their current facility, so they know they need to expand and build a brand new campus. But she still has to balance repairs and upgrades to their current facilities, since those are going to continue to be used while the new campus is being built.

Pie Chart showing examples of categories like existing maintenance, new buildings, etcIn our organizations, this duality of building a new campus versus maintaining the current one comes across as building new features (or gaining new capabilities) versus maintaining existing systems or running the business. Some percent of our budget will be used to fund maintenance (sometimes called “Keeping the lights on”), and some percent will be used to fund things that will help grow the business. The goal as a business leader is to make sure that the funding percentages balance out the needs, and that what gets funded in each bucket is done in a way that moves us forward as quickly as possible.

So back to Roberta. She has a plan for handling the existing buildings, but is trying to figure out the best way to tackle the new campus. She has a list of all of the things they are going to build there:

Building plans showing the sanctuary, gym, office and activity fields connected with walkways

  • A new Sanctuary, which will be where Sunday services are held, as well as special events
  • A new activity field, where they can hold outdoor activities like Soccer, softball, or picnics
  • New administrative offices for the staff
  • A new multipurpose building with a gym and classrooms

Right now they meet at a local school, and they have office space they are renting, which also has a hall they can rent out for special events.

The above list are incremental pieces of the entire vision. By completing any one of these, the overall vision gets moved forward. But which one should be first? Or should they build them all before taking advantage of any of them?

Group of women leaders sitting around a conference tableTo answer that, Roberta and her team of leaders needs to know what their needs are as an organization. She knows they want to grow the number of people that can attend (and for sure not lose anyone because it is too crowded). She also knows that the current flow on Sundays doesn’t work well because, well, they’re meeting at a school that was not designed for their needs. She also knows that if they keep growing and not moving, they may run into fire code problems with too many people. And finally, all of the money they put into the school is money not going towards their future.

These criteria can be mapped to the kinds of things businesses look at:

  • Growing the business
  • Retaining existing customers
  • Improving how the business runs
  • Regulatory compliance
  • Cost reduction

With her criteria in mind, Roberta and her team rank the things they want to build:

  • A new sanctuary would help with the overcrowding of services, but would not help with many of the other activities and events they want to host throughout the week. It’s a specialized building, so it ends up at the bottom of the list.
  • The new activity field would enable a lot of outdoor events, but would need shelter in the case of rain, as well as bathrooms and other amenities that were planned to be handled by having the activity field near the multipurpose building.
  • The administrative offices aren’t a dire need – the space they have now works, although the hall rental can be a pain, so it would be good to have some place to hold those events.
  • All of the factors point that the multipurpose building makes the most sense to have at the top of the list. It will give them a place to meet (during the week, as well as on Sundays), provide the amenities for the activity fields, and solve the need to not have to rent the hall.

Roberta and her team feels great about this ordering. Within 12-14 months they’ll have a fully complete multipurpose building with a gym, classrooms, and amenities.

If only they hadn’t stopped, they would find an even better solution.

Minimum Increments

Child kicking a soccer ballIt turns out that one of the big gaps in the community they serve is a lack of soccer programs for youth. There are several programs they can partner with that would draw in a large group of people who could all be potential attendees of the church. But the season starts in 5 months, and they aren’t planning on even starting the activity fields until after the gym is built.

Looking at the requirements for the soccer program, they have the following requirements:

  • 2 soccer fields (which don’t have to be regulation size)
  • Some sort of a shelter
  • Access to bathrooms

Taking the multipurpose building as a whole, Roberta’s team can work with the contractors to figure out smaller pieces of it they can build. The contractors state that the entire foundation has to be poured at one time, but they could then build just the bathrooms and extend the rest of the building from there. There would be a slight increase in cost to do it that way, but they could have the foundation and bathrooms done in 2 months. In the meantime, Roberta talked to the contractors about the fields – they could easily build a single regulation-sized field in two months – it wouldn’t have the lighting systems in place or the sprinkler systems, and they may have to dig up the field after the first soccer season to install those.

What is happening here is that Roberta and her team are taking the initial increments and understanding (with expert help) how they can be decomposed into smaller increments. They are then looking across all of the areas and composing a minimum increment that will solve a need or gain a capability for their organization when it is done.

Construction Begins

Laptop computer sitting on a desk with hands typing on it

With a plan locked in place, Roberta funds the plan, and work begins. The foundation pour goes very smoothly, and the walls begin being built. One afternoon the contractor calls Roberta and her team to the job site:

Hi Roberta! I know that we’ve spent a lot of time looking at plans, so what I wanted to do was have you take a peek at the progress early on to make sure this is looking how you imagine. I had the brick layers build up just to the door frames and window frames, and given where you have the activity field, I wanted you to see if this matches what you expect.

This action by the contractor involves building the first pieces iteratively, by putting a little in place, and then seeking feedback. The first iteration – putting up the door frames and windows – doesn’t give a completed increment. But it does give room for feedback from the customer (in this case, Roberta) and encourages everyone to be on the same page before moving forward.

Similarly in our organizations, we want to strive to be as iterative as we can in building increments. Specifically we want to build small slices of functionality that can be shown. My dear friend Jared Richardson refers to this as Tracer Bullet Development where each iterative slice gives us increasing information and confidence that our increment is on target. Even though the contractor could have built out all of the walls before seeking feedback, by doing the minimum he could in as integrated of a way as possible, he allowed rapid feedback and adjustment – even in a construction project!

Pulling It All Together

Roberta was able to take advantage of a new opportunity by knowing what her goals were, what capabilities were needed for those goals, what increments built those capabilities, and how the increments themselves could be decomposed across her vision into smaller increments, and then composed together in a new way. Once the increment was funded, her team was able to take advantage of the contractors iterative approach to update things with new information.

Graphic showing goals mapping to capabilities, which map to increments, which then combine into minimum increments

It can be easy for organizations to do an initial decomposition into ideas, call those “increments” and feed them to teams, especially if those teams are building it iteratively. But as we saw with Roberta and her team, being able to go one step beyond that – knowing the capabilities, decomposing the increments themselves and using the visibility across the portfolio to recombine them into increments that form exactly what we need to take advantage of market opportunities – is a level of agility that can transform businesses.

(Note: The pictures of “Roberta” and her team came from the amazing “Women of Color in Tech” project offered under a CC Attribution license to #WOCInTechChat. Thanks – they’re amazing!)

{ 1 comment }

What Is Agility?

In my last post, I gave some examples of the difference between Implementing Agile and Transforming to Agility. But like the term “Agile”, agility is an often overloaded term that means different things to different people.

When I talk about agility to clients, the conversation focuses on the agility of the business, which is different than, “we’re delivering what the business is asking us in an agile way”. Organizational agility goes far beyond the team and encompasses several different areas:

  • At the business level, the executive team is thinking about gaining capabilities by focusing on smaller increments of work that can be done in less than a quarter. The entire portfolio is sequenced to fund initiatives that take advantage of market opportunities, meet regulatory needs, and move the business forward across divisions and teams.
  • This means that specific skills are needed throughout the lifecycle, so managers focus on growing skill sets and getting the right people available at the right time by building teams or working with vendors. One specific change here is how job descriptions are written and performance reviews are implemented to focus on collaboration instead of solely on individual contribution.
  • At the team level, all of the things we’re used to still apply: good development practices, iterative delivery of work, high visibility in short cycles, integration of design, testing, development, analysis, etc. If teams are producing large, stinky piles of poo, they’ll either sabotage the efforts above, or end up being replaced.

  • At the technical level, the view becomes about technical capabilities across the portfolio, and how business needs either innovate or reuse these capabilities. This includes strategic architecture, systems evolution (and retirement!) and organizational adoption and change towards DevOps, Microservices, Mobile-First strategies, etc.

Woven throughout this is the principles of Lean Thinking – how quickly and smoothly things flow through the cycle, how we visualize bottlenecks, and how we continually learn and improve.

Amazing things happen just by gaining agility at the team level, or scaling the team level. But a business firing on all of these cylinders is an amazing thing to watch.

{ 0 comments }

Implementing Agile, or Transforming to Agility?

Implementing Agile practices is easy:

  • (Manager to team): “You have new roles! You’re the ScrumMaster, you’re the Product Owner, and the rest of you are the team.”

  • (Manager in meetings): “And we’ll have these new meetings! You all will get together once a day to talk about your progress, and every two weeks you’ll show the product owner what you’ve done, and she’ll tell you what’s next”

  • (Manager shaking paper): “And I expect status updates via updating the backlog and the Scrum board!”

With those things in place, a team can claim to be “doing Agile” (or, at least, doing Scrum). But our goal is not to be doing Agile, or Scrum. It’s to have agility, to transform our work.

In the book “Managing Transitions“, William Bridges talks about his model of change versus transitions:

The starting point for transition is not the outcome but the ending you’ll have to make to leave the old situation behind

So while it’s easy to implement agile, the transition to agility for a team is hard:

  • (Manager to team): OK, so team, I need you to stop doing things sequentially, and instead work together collaboratively. That means stop with silos, stop doing big design up front, stop doing test last, stop digging in really deep without thinking about what the goal for the next two weeks is, and stop hiding from the team.

  • (Manager to business): I also need you to stop throwing things over the wall and handing over completed specs. We want to collaborate on the solution, so stop wanting absolutely everything as well as waiting until the very end to review.

  • (Manager to managers): And I need you all to stop assigning tasks, doing performance reviews based on individual contribution, siloing teams, and demanding detailed status updates

(And yes, it’s all relative – if the “implementing” part is hard, then transition is exponentially harder)

If transition is what you are looking for, then get in touch today!

{ 0 comments }

“This is awesome!” Jenny, the Product Manager exclaims to the team. “We’ve been having some challenges retaining customers, and I think we’ve got just the right idea of how to fix it! It’ll require a little retooling of our sign-up flow, but I think the impact will be incredible.”

Great ideas are some of the most powerful accelerants there are. Lighting one off produces a great burst of energy, light and acceleration. But like great accelerants, it burns out very quickly if it doesn’t have clear direction and sustaining energy. Ideas in software can be especially fast-burning as we try to convert an idea into actual, working software. Not only do we have the idea itself to contend with, we have to integrate it into systems that probably weren’t conceived with the notion of this incredible new idea. That can lead to friction, bugs, and downright failure to launch.

Having worked with many teams like Jenny’s, there’s a common flow I’ve begun sharing around the notion of how we can take ideas in all their uncertainty and get them to production with a high level of confidence. This isn’t a new model by any means, but highlights where steps should be at and a flow that has worked well with teams I coach.

Picture of a model showing steps progressing towards confidence

We start with a wide interpretation of what the idea is. We take steps during development to focus that interpretation into a clear, releasable chunk. Once we’ve committed the feature, we have a clear of idea of what we wanted to build, but not a high confidence that is working as we intended. So the second part of the diagram moves us to that high level of confidence by using the work we did to gain understanding and clarity to also gain confidence.

Let’s dig a little more into these steps.

Development Cycle

At the top, we start with an idea. We write Acceptance Tests to capture the high-level goals. This is ideally automated (using something like Cucumber or FitNesse), but can also include things like “We expect to see a 3% increase in conversions”. The point here is to develop concrete, measurable business objectives and goals for the outcome of the feature.

As we’ve begun capturing our acceptance tests, the team starts looking at how things integrate into the system, using Integration Tests. Here we think about how the feature will be put into the system, and write tests to capture what will happen once the feature has been integrated. These will not be passing, because the feature hasn’t been written yet, but will begin letting the team think through the integration questions and challenges.

Similarly, if we’re integrating into an existing system, we may need a series of Regression Tests to capture how the system works now to make sure it continues functioning as expected. For example, if we’re adding a new module to accept gift cards, we may need regression tests around calculating tax, or total costs when there is no gift card. This gains us confidence that the new feature won’t have unintended side effects.

In parallel, the developers will start writing Unit Tests (ideally using Test-First Development) to capture the behavior and functionality of the code they want to write. These tests are focused at a low-level of functionality, and help drive out the design of the actual feature. These are paired with writing the code for the feature itself.

Finally, many teams use a Code Review process to look over the feature. This could be done in real-time using Pair Programming, or through a Pull Request process, or just simply emailing team members. The goal here is to think through the logic from an outsider’s perspective, and also give information about how it integrates with the system.

With our tests written, our design reviewed, and our clarity sharpened, we commit our code and begin our deployment cycle.

Deployment Cycle

Throughout Development, we write tests at various levels not just for testing purposes, but to drive out the understanding of how the code functions and integrates into the system. But at some point we need confidence that we’ve done what we needed.

So once code has been committed, it begins a workflow of gaining confidence. Immediately after code is checked in, the unit tests are run. This gives fast feedback about whether we’ve broken anything, or impacted code quality. We can also run Static Code Analysis, Security scans or other tools to make sure we’re following our team’s standards.

If our unit tests pass, we can now start digging deeper into the viability of our code. We start by deploying it – ideally to a test or staging server. These servers will have the data and access to run scenarios. We can then execute our integration and regression tests, ensuring our system is functioning as expected, and finally executing our acceptance tests to make sure we’re meeting the business needs of the feature. If all of these pass, we’ve widened our confidence in the feature.

Cycles are actually continuous

So while this is laid out as a single workflow, the idea is to use automation and close collaboration to keep these cycles continually flowing. Being able to know within 10 minutes that a change a pair made to the code impacted conversion rates is a life-changing thing for many teams, allowing them to respond very quickly to the needs of the code – and the business.

{ 1 comment }

Prioritization vs Sequencing

When teams get introduced to various agile methods, one of the seemingly easy aspects is the notion of the product backlog. They then ask their business parts to prioritize the work in the backlog so the team(s) can pull the highest priority item.

It sounds easy because people think that priorities are binary. In reality, multiple things can be the highest priority. For example, a company might have a mandate to deliver a specific type of reporting feed to a government agency, while also needing to hit a critical product launch. Both are high priority, and would be “tied” for the top spot.

I often get around this by introducing sequencing as a distinct concept from prioritization. For example, in our above scenario the government report might take about two weeks of effort, while the product launch is 6 weeks of effort. If both are due in 8 weeks, we can sequence the work to hit the most critical portions of the product launch for 4 weeks, work on the government reporting feed for 2 weeks (giving a 2 week buffer), then finish up the product launch.

So if you find yourself struggling with “prioritizing” a product backlog with business partners, try talking about sequencing instead. That’s what you are really aiming for anyway, and opens the door to richer conversations about risks, costs of delay and business value delivery.

{ 1 comment }

A quick protip – if you are projecting (say for a conference or training), want to have your screen split (so it’s showing different things on each screen) but still want to show what you are typing in your terminal, you can use tmux to have it mirror what you are typing in a separate console window.

First, install tmux. If you are on a Mac and use Homebrew, you can do brew install tmux.

Once you have tmux installed, open up a terminal window and start a new tmux session with the following command:

tmux new -s training

This creates a new session on your localhost named training. Next, open a second terminal window and run the following command:

tmux attach -t training

This “attaches” the second window to the first session. Now, whatever you type in one terminal window will show in the other, and vice versa. It will even show you if the viewable area is smaller than your current window, so you know what the other screen will see.

{ 0 comments }

2015 Can Bite Me

At first it seemed silly to me to post a “2015 review” as if I do anything all that interesting, but I also know it’s good to step back and reflect on things, so here goes.

2015 can bite me.

I don’t want that to sound like everything was horrible. Back in June I came on board at The Iron Yard to build their Corporate Education / B2B business, and we’re building some incredibly awesome stuff that will be hitting hard in 2016. In addition, I got to play a tiny part in helping bring an awesome new platform for the deaf into play (much bigger kudos to VTCSecure who actually has been working on it for years to bring it to fruition). I also launched an apprenticeship program at my former employer based off of the 8th Light model.

I did some fun talks, too:

Outside of that, this was one of the most challenging years I’ve ever had, even blowing out of the water the time we bought a house and got laid off right after. The year started off promising enough with a new position as the CTO of a local company with 30+ developers, many who I knew personally. There were some interesting projects in the pipeline. But then the worst possible series of events that could have happened, did:

  • The team was behind on a critical project with tight deadlines. I was able to rally the troops, and by putting in an extraordinary effort (the final week I believe we worked well over 100 hours) we shipped it.
  • However, in the midst of that, my dad got extremely sick. He had to have emergency surgery, and we brought him up to stay with us. During that final project push, my dad had developed a blockage in his intestines that I should have been able to catch, but didn’t because I was at work.
  • So the day after we shipped, I ended up in ICU with my dad, where he spent 10 days in the hospital. I was then able to transfer him back to Florida where he ended up in the hospital twice – with me making frequent, frantic drives to Florida from NC – before he passed away in May.

I questioned a lot the decisions I made balancing work and family. Ultimately I couldn’t have predicted things happening as they did, and wanted to be able to be there for my team and my dad. You can’t take back decisions you made, and as much as I talk about work/life balance, I made a decision to not focus on my dad as much as I should have. That’s rough.

Looking back, I’m incredibly grateful for many things:

  • A strong family that has supported me
  • Friends I could bounce ideas off of
  • An awesome team at The Iron Yard who understands diversity and how to make people successful (even if we’re still figuring out the growth thing)
  • An amazing group of people I met this year on the Twitter that inspires me: Saron Yitbarek with Code Newbie, Cate Huston, Lesley Carhart, Carina C. Zona, Keri Karandrakis (and her Tweet heard round the world), Coraline Ada Ehmke for her journey, and Ruth Malan for her incredible generosity and motivational tweets. And let’s not forget Taylor Swift for helping expand the reach of security topics to more people than anyone could imagine.

I’m excited by what 2016 is going to bring. Maybe it’s just me coming off the first vacation I’ve had in years, but there is a lot of amazing things all coming together, and I’m ready to uncork a bottle of fizzy drink and celebrate the end of The Year That Shall No Longer Be Named.

So 2015, I leave you with this:

Bite My Shiny Metal Ass

{ 0 comments }

Huge thanks to Red Hat for having me out for Red Hat Agile Day 2015! Below are the slides from the talk!

Update: The talk was recorded! The video is posted below under the slides!

Strategic Play from Cory Foy on Vimeo.

{ 1 comment }

Why are my commits attributed to devil man?

Last night, a scary looking message came to me from our Slack channel:

Slack message asking if a commit was mine

We were referring to the user as “Devil Man” because this was his profile picture.

Picture of a devil looking cartoon

After wondering if perhaps my ssh keys had been compromised, I came across something that makes way more sense, and isn’t sinster at all. I ran the following command on my laptop:

Corys-MacBook-Pro-2:~ foyc$ git config --list
user.name=BuildTools
user.email=unconfigured@null.spigotmc.org

Turns out, I have a new laptop that I haven’t configured with all my dotfiles, etc. However, I was playing around with a Minecraft/Raspberry Pi server, and pulling down the tools set my global Git configuration. Since I didn’t change it to anything else, the PR I sent got pushed up with the above as the configuration, and “Devil Man” must have that as his GitHub repository email, so GitHub helpfully linked the two.

Thankfully this wasn’t a security vulnerability per se, but in case you ever wonder why your commits are attributed to Devil Man, now you know that it isn’t his fault, but your own for not configuring your commits properly.

(For futher reading, GitHub has a more boringly titled article “Why are my commits linked to the wrong user”)

{ 0 comments }

This week I had the privilege of sitting in for the great Jared Richardson and giving his Continuous Testing workshop at SQE’s Better Software West. I added my own flavor to various parts, and wanted to post the slides for participants. If you are interested in finding ways to improve your practices, be sure to reach out!

{ 0 comments }