Plans for Xmas

December 17 2017

yesterday I heard my little daughter being told by her mom “honey, let’s prepare a list for tomorrow shopping!”. don’t ask me why, but I then started thinking about one of my favourite topic in software development: release planning.

imagine you’re working on an aged software application for your company (eg: an online travel agency), composing products from 3rd parties resellers (eg: flights, train trips, hotel accommodations), adding some extra markup, and selling as bundles (eg: holidays). now imagine that your company aim to add an additional product (eg: additional baggage on flights), available from many of the existing resellers, but not yet part of your offering.

imagine that, from a quick analysis and market research, your company define an initial release around integrating products from a few resellers only (eg: additional baggage from 5 topmost airline companies).

lastly, imagine that your software application has been migrated from a monolith to an (almost) microservices architecture, so that you have dedicate backend components for topics such as resellers (eg: airline/hotels integrations), bundles (eg: markup rules, market-specific composition rules, etc.) and a frontend component for interacting with users.

how would you then approach release planning for the very first project release?

let’s try listing all activities to be performed, such as:

  • collecting products details from resellers (eg: parsing XML or JSON payload in airlines HTTP search API responses)
  • storing new products into catalog database (eg: adding BAGGAGE table vs. adding BAGGAGE type in PRODUCTS table on RDBMS)
  • defining markup rules into bundle database (eg: extending rule engine with new
    BAGGAGE product type)
  • preparing new UI for showing new products details and selecting desired products (eg: simple “baggage-shaped” widget for all available sizes and weights)
  • storing selected products on orders database (eg: full baggage details vs. a reference to available baggages previously collected, stored into ORDER_ITEMS table on RDBMS)
  • purchasing selected product from resellers (eg: adding XML or JSON content to airline HTTP booking API requests)
  • adding purchased products details in confirmation email (eg: simple statement with quick recap on allowed sizes and weights)

that’s a lot of stuff.

there are many risks, probably most related to external service APIs, because they’re not under our control (are those products available to be purchased on test/sandbox environments as well?). but also from a domain perspective, modelling these new products could imply tricky challenges, such as full-details vs. reference storing, reuse existing products and orders details models for sizes/weights as well.

one first approach for planning a release is, well, simply plan those activities in that exact order: start parsing API responses, end with updating confirmation email. in the end, that’s the work to be done, isn’t it?!

let’s call this a “task-oriented” release planning. in fact, that activities smell like programmer tasks: technical, “horizontal” (impacting one layer/component at a time), simple to be performed without additional context (eg: what’s following next). you’ll probably “see” some visible behaviour only at the end of the whole release, or at half of the release: new UI for users and new sentences in confirmation email, which should both be “feature-flagged” off unless the release is complete (but feature-flagged on in QA env or for some test users).

a second approach for planning a release is forgetting about components/layers boundaries and start focusing on users, being that both customers and admins. in other words, focusing on visible behaviour, eventually adding minimal tooling for making it really “visible”. in the example, we could have:

  • dashboard with available products, for admin users (eg: listing baggage that would be presented to real users, for supported companies)
  • new products checkout, for real users
  • selected product purchasing, for real users
  • selected product details in confirmation email

let’s call this a “feature-oriented” release planning. items in this plan are almost functional, “vertical” (impacting many components/layers). risks with this approach is having “long” development activities, before considering “done” a feature. with this approach you’ll learn what incremental development is: adding, one piece at a time.

as a note, I’m referring to the term “feature” as nowadays presented in SCRUM-like release planning: something understandable by C-level executives. I don’t really like the term, I’m used to call them themes (or epics, with no particular distinction even if one exists, by the book). anyway, let’s stick on this for a moment.

one third approach for planning a release is slicing features, trying to keep them as slim as possible, but still vertical. the very first user story will look like to something like this:

  • focus on the very top reseller only (eg: only one airline company)
  • suppor only one fixed product on that reseller (eg: only 1 extra baggage),
  • enable on a small percent of orders (eg: only flights internal to that company main country, where no currency/units conversion is required)

you’ll then move either to more resellers, more products or more orders, according to your company strategic vision and to feedback collected while developing.

let’s call this a “user-stories-oriented” release planning. you’ll probably explore much of the complexities as early as possible, using simplifications to let you go faster. you’ll surely have then change components/layers many times, as you progress in the development. with this approach you’ll learn what iterative development is: rework, from simpler to more defined.

given this long introduction, and example, my very personal suggestion (biased from an XP style for planning) for doing release planning is starting with features (or themes, as I call them), and then move to user-stories. I know, not much original content here (in fact, I’ve been sharing thoughts like this since many years)! sorry mate :)

anyway, two additional hints:

  • don’t focus on tasks (as in the first approach) in the beginning, but let them flow as you’ll start analysing and estimating user-stories. an high-level technical architecture is enough to start planning a release (and later releases as well)
  • don’t have separate release plans, one for C-level people with features, and one for development people, with user-stories. this would require continuous “mapping” between the two. stick on one shared release plan, share on the company wiki, print it and put on walls, update it often

don’t get me wrong, you’ll probably require an higher-level plan for executives, just don’t call it a release plan. I’ve seen referred to them as initiatives or goals, but have not much experience with.

surprised by such a long post, after almost 4 years and an half? don’t tell me, I’m astonished as well! well, let’s consider this my Xmas gift for you!

Advertisements

hold on for a few hours more, then hurry up! Italian Agile Day 2012 is coming on November 24th!

I’ll be presenting a session on projects evaluation, aiming to put together my past few years personal experience. this is such a interesting topic for me, combining both organizational and technical skills.

I’ll be sharing with the audience techniques for documenting and reporting software project feasibility: coarse-grained release planning, high-level logical architecture, rough delivery effort estimation, basic domain modelling. whatever simple enough you need to get started with a project kick-off. possibly.

see you in Milan!

Remarkable quotes

May 3 2012

sort of an ipse-dixit saga starting here..

iterations are means, not an end. incremental development clocked by fixed-length iterations sure is a great achievement, when starting from a “big ball of mud”-like environment, where no process is applied at all. coding rhythm like “need this in production by tomorrow, can you do it?” isn’t sustainable, so planning one to three weeks long iterations is the way to go.

then – because there should be a “then” – next step is asking business to figure out where to bring the project to: medium-term to long-term goals, also known as releases. the opposite can’t stand: filling up iterations with something good-enough to keep development team busy. iterations are means – achieving business goals on a regular and reliable basis – not an end.

coolness isn’t cool. developers often tend to be delighted by techy/geeky stuff. “I’m working on this ultra complex semantic search algorithm which is going to improve performance by a 24.7% factor!”. “we just integrated X with Y, in a clustered Z environment, only by configuration files!”. don’t get me wrong, I’m far from demonizing this kind of focus on technological issues.

but – because there should be a “but” – we, as developers, are in charge of much more: helping stakeholders achieving their goals, managing software development projects, planning releases, architecting and designing systems. we’re not just coders, our value isn’t counted by how many lines of code we can manage to write in a single pair of curly braces. coolness – complex problems and technologies on hype as ends in themselves – isn’t cool. delivering successful projects is.

yep, philosophy was my first love..

Release the dogs

December 17 2011

I’ve been thinking about this post since a few months, and I’ve now got some more data to share about. the title stuck in my mind while listening to “Tomorrow Come Today” Boysetfire’s album, driving back home after an intense day of working with the team.

it all started in a study session on the XP practices, discussing what was stopping us from applying some of them. for example, Small Releases. the immediate objection was “well, we deploy more than once a week!”. in fact, user stories are moved to production as soon as they’re completed, validated and accepted. so, is this a non-sense question?

this week we kicked-off a new project, which is critical, because it aims to improve the company product’s core. the stakeholders asked for a technical solution that could answer the question “is this worth it? does the company receive any benefit from the new business rules”. so, we agreed on an architecture that keeps the two sets of rules in parallel for a short period, and as soon as we collect positive data, we’ll switch the product to the new system.

it took us two days to come with a Release Plan and an Iteration Plan for the first iteration. we collected themes and user stories, discussed a feasible architecture, then set rough estimates. this initial process showed we could answer stakeholders’ question in less than one month. then, it would take us another month to develop enough user stories to switch to the new system. eventually, we could then focus on the less important themes, which we didn’t even analyzed nor estimated, just tracked down on index card.

to recap, we focused on the smallest chunk of stories that could be put into production in order to bring value as a whole, and a release date has been attached to. then we iterated this process. the result is a three-releases plan, which is being adjusted and adapted whenever we found something new about estimates, technical risks, and the domain itself. we also know the first release it’s about two iteration long. then we know what’s going to be developed for the next two weeks, in much more detail, having discussed acceptance criteria and technical alternatives.

back to the initial study session, I think the problem is due to the fact we talk in Italian. the Italian for “release” and “deploy” is exactly the same: “rilascio”. we say “piano di rilascio” for “release plan”, and “rilascio in produzione” for “deploy to production”. combine this whit the continuous delivery practice gaining more and more popularity these days, and maybe the communication problem gets explained. to be fair, the project we referred to, deployed on production frequently, was more in a maintenance than a developing phase. there was no clear reasoning about planning. hence the confusion.

to recap, and to state a take-away message: don’t confuse release planning with production releases, especially if in your native language the two words sounds similar. my suggestion is to mentally translate to “milestones” for release planning, and to “deploy” for production releases. would this help you?

In my shoes

July 19 2011

back from an amazing journey in Crete: 11 days, 5 main cities, lot of beaches and towns only by public transports, hostel by hostel with a light backpack. can’t count how many buses and boats I’ve been taking. and, best of all, people I’ve met.

here’s a quick report:

  • day 1: plane from Milan to Hania. Agioi Apostoli and the Kalamaki beach
  • day 2: Gramvousa island and Balos beach, by boat
  • day 3: bus to Paleohora. sandy beach and pebble beach
  • day 4: Elafonisi beach and island, by boat
  • day 5: boat and taxi to Plakias, via Hora Sfakion. Plakias beach
  • day 6: hiking to Moni Preveli (Preveli monastery), then palm trees beach. way back by boat
  • day 7: bus to Rethymno. beach and old town
  • day 8: Panormo beach, by bus
  • day 9: bus to Iraklio. old town
  • day 10: Agios Nikolaos, beach and town, by bus. Kolokytha peninsula and Spinalonga island, by boat
  • day 11: Cnosso palace, by bus. historical museum and archaeological museum. plane to Milan

following is the initial plan, but of course, as any well-done plan, it has been adapted day by day:

pictures here.

sure, it’s been a tough journey: hostel owners were impressed by my willing to see as much as possible in so short time. sadly, I could not visit eastern coast, like the Vai beach. that could probably be the goal for another journey!

Vision ownership

July 5 2010

as developers, we try to find solutions where problems arise, ideas to get customer gain value from our systems. as eXtreme Programmers, we then try to do this driven by simplicity, communication and feedback. the smarter we are, to more satistied the customers become. but there’s always something strictly domain-dependent, no easy to see being a cunsultant.

that’s where a good product manager comes in.

I’ve been playing with search facilities provided by CMS platform we’re developing on, two days or so: rich fulltext search, simple search component, even custom low-level queries, but neither of them were good enough to support (not-so) complex scenarios given. so, I started focusing on getting simpler searches done, vertically splitting stories, even horizontally on technical-axes (like delaying result pagination). but this keep-on-cutting process left me with almost empty hands.

simple search delivered, asked PM for feedback: it tooks her 30 seconds to say “let’s move to (internal) search engine”. period.

of course, it does make sense, now. but no one in my team came with this idea, focused on solving problem at hand. and yes, it’s “easier” for us because we’re asking someone else, from customer’s internal staff, to work on custom search profiles, while we’re focusing on UI and search integration. what’s important, anyway, is product integrity: something hard to come with.

what’s the morale? quoting Dan North’s Perils of estimation:

The business started out by defining success as solving the problem, but now we have redefined success as delivering this list of stories.

he then goes further, with this evergreen:

Firstly the business wants accuracy and we’re giving them precision. If you tell me it will take 4.632 months and it takes 8 months, that’s worse than useless. If you tell me it takes “about six months” and it takes seven months, I should still be onto a winner.

estimation helps plan a project, stories define business goals “tokens” we gain every week: but ultimate goal still is satisfying customer needs (asking for feeback and showing working software), not collecting those tokens while on a project journey.

Killing me softly

May 7 2010

continuous task switching: that’s it.

can’t manage to work developing one project, following production setup for a second one, doing email/phone consultancy on a third one (where I’m officially no more involved), then helping colleagues in Rome spiking around with a fourth one.

I’m broken.

even more, our near past and future involvment as a team on customer-side is managing a pipeline of (initially) four projects: then (working targeting success) this is getting broader, and more projects are expected to be started on a monthly basis. this is probably the most interesting thing: a shared release plan, one team, more projects.

and a single source for budgets. expect more on this soon..