What do we do now? How to start that next project of yours

September 17, 2016 · Agile Scrum User Story Retrospective

To do List

[Disclaimer: acid tone inside :P]

Hey, you've been promoted to a new and exciting project? How nice for you. Congratulations! No irony. Almost. Unless you've been downgraded to this project and then it was definitely not ironical but cynical. Anyhow, here are some things you should consider before starting it.

For sure you can discard every one of them if it pleases you, but I'd recommend giving it a good backrub first... just in case.

Without further ado, let's hop in.

1. Customer

DO.YOU.HAVE.A.CUSTOMER? Don't laugh. Of course someone is paying for the stuff, but do you have a "customer"? I mean by that someone that will use it, someone that knows what is needed, someone that can show you the ropes and drive you through the development process from a... customer point of view? If not, just go cancel the project ; catastrophe avoided. My pleasure, you can thank me later. If you want to offer me a beer to say "thank you", you know where to find me. You'd never guess how often it happens... I mean having no customer, not offering me beer ; this never happens. Unless. No. Anyhow. I'll assume you said "yes".

Is this customer of yours available? No? Just go cancel the project ; catastrophe avoided. My pleasure [...]. Is s/he aware of what it means to be "the customer" on an agile project? By this I mean:

  • Available: Able to sit with you on a (very) regular basis and take some time to work with the system
  • Knowledgeable: Able to tell you what the system should be doing
  • Authoritative: can prioritize features and even erase some from the roadmap at will i.e. has life and death powers over any part of the project

If any of the points above is not present, think twice, it might sting. And I know what some of you will think: we don't need all this, the "customer" went to the trouble of describing everything s/he wants in a nice big and fluffy document. We're all set, we just have to follow the breadcrumbs and we'll make out of the woods eventually. Remember that if the original "Hop-o'-My-Thumb" story closed on a happy ending, before they made it out of the woods, seven daughters had died in the process... funny that a Scrum Team often revolves around 7 members as well...

Communication is a thorny thing. If you need convincing, try this game: dispose half a dozen objects on a table, over one another, in balance... however you wish. Then give someone - who has not seen this setup - the same objects and have him or her re-create it based only on a description someone else makes. You can try it verbally (with or without allowing for questions) and you can try it in a written form. I promise you chaos. If we are not able to correctly communicate with 6 objects in mind, how in hell can we assume we will be able to describe complex software projects with hundred of pages AND get what we really want out of it?

Such a requirement document is not bad, it is a good basis, but it cannot, I insist, CANNOT replace customer communication. Period.

2. Vision

Do you have a vision? If not, I'd recommend mushrooms. Let's consider a troop of adventurers in the wild, each person having a compass showing a different north. What is the likelihood for them to arrive quickly - let alone safe and sound - at their destination? Without vision, everyone on your team can have his/her own north, fun guaranteed!

The product Vision is one of the most important thing your project needs and one of the most-often-forgotten part.

“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68)

The vision should be "clear and stable", "broad and engaging" and "short and sweet" (Roman Pichler 2009). Subject your vision to the elevator pitch test. Can you create a vision that answers the qualities stated here above and can be expressed in the time lapse of an elevator ride? And let's assume space elevators don't exist yet.

Before we go on, I'd like to push back on your vision first. Eric Ries, creator of the "Lean Startup" movement said:

"Having a successful startup has less to do with coming up with a brilliant idea and becoming a success story overnight than with testing and learning faster than your competitors"

In other word, you don't come up with the winning product by accident, you work on it, formulate a vision, try to make it a reality as fast as you can, learn and iterate. So did you validate your vision? Did you create a minimum viable product and ask your potential users for feedback? Did you create a business plan that will make your effort worthwhile? Do you know how to market the product you will end up creating? Don't end up with a vision and no-one to share it with...

3. Personas

Do you understand you users?

Nota: if your answer is something along the lines of "users?"... you might have a bigger problem. See the part about canceling the project and paying me a beer..._

A user persona is a representation of the goals and behavior of a hypothesized group of users. In other words some kind of "user profile".

Create a list of the different users that will have their hands on your system. Give them names and pictures, define where they come from and what they do for a living. Add the sports they like and what they eat for breakfast. You can even define some past and now difficult relationship between some of them to spice things up. Yes, definitely do this. Don't forget to clarify what is important to each of them, what motivates them to use the system you might soon end up creating and what will make them use it, evangelize that system... or maybe leave it. Depending on how well you intend on undermining the project, you might want to keep the last part for yourself.

Post those profiles prominently on the wall, learn their names by heart and place them in your user stories. Heck, invite them over for diner some time, you will need their help soon.

4. Backlog

Now that you have a customer, some users and a clear vision, now all you need is love... and a backlog.

A good backlog should look like an inverted pile of rubble. The bigger backlog items are at the bottom whereas the small items swim on the top.

In "Safe For Work" vocabulary, it means a lot of things. First, most of your product is somehow described in your backlog. Then, since your backlog is prioritized... wait a second, it is prioritized, right? Good. As I was saying, then since your backlog is prioritized, you can work on defining really well the top items and leaving the rest for later. The top items are the ones you will tackle very soon, thus you need to really get to the bottom of them. The farther you go down the backlog, the coarser grained the items will become ; and that's OK. As long as you continuously refine the top items as you go in order to always have some work ready.

5. Methodic

The previous section about the "Backlog" clearly reek like agile stuff ; which should be no surprise to you since I'm paid to do some agile voodoo after all. But I'd dare say that until now everything you've read is only more or less common sense and has little to do with one or the other methodology.

What is left for you to adopt is some kind of regular inspecting and adapting. Give yourself a feedback cycle, some kind of regular deadline. Inspect and adapt. Rince and repeat. If you stick to this simple inspect and adapt loop, you will be able to find your way to success whatever the methodology you pick.

Name that however you want: "Scrum", "Kanban", "Iterative Something", "Agile Coach masturbation" or "Far west 3.0", I don't care. Just. Do. It.

Then make sure it is clear for everyone on the project how you intend to work... which leads us to the next point.

6. Roles

What is Jean-Claude supposed to do on this project? How about Helga? I don't like putting people into boxes either, but some kind of responsibility definition will help you avoid future arguments. Feel free to refine those as you go. The most important part is the identification of those responsibilities, not so much who will handle it. Once this is done, you won't be able to ignore it for long and the roles will fill themselves up.

We already discussed the customer in length. Is (s)he still there? Somebody will need to fill up the backlog. This typically falls onto his/her lap. If not, make sure you know who will... and make sure (s)he knows it as well. In Scrum terminology, there could be a "Product Owner" (PO - which means "butt" in German... some things are accidentally perfect aren't they?) to act as a customer proxy... but one way or another, someone with deep knowledge of "what" is to be built should handle that part.

Beside the product owner, there should be somebody overlooking the way you work. Call him/her (or me for that matter) coach, Scrum Master or babysitter... that's up to you. But make sure someone reminds you of the rules you set yourself and keeps the inspecting & adapting goodness coming. If you setup some rules and do not follow them, how can you tell if 1) the rule was wrong or 2) the people screwed up, when something goes south? The key here is accountability, for your very own sake.

Last but not least, you will need "code-dolphins". We usually say "code-monkeys", but we'll need the smartest fins on deck. So exit the monkeys, we'll go for dolphins! Those have to be able to do the work over the whooshing sound of deadlines passing by and the customer breathing down their neck, that is:

  • Helping the customer express him/herself and understand what (s)he really wants
  • Code and quality proof the damn thing to the bone
  • Organize the DevOps pipeline to have it pushed all the way to production without breaking a sweat
  • Self-organize and reflect every so often
  • Have fun in the process

I told you, Dolphins, really! Or unicorns even.

You might need some other roles, but please, Please, PLEASE (!) refrain from creating different teams based on them. That means no "Test Team", no "Requirement Engineering Team" and god forbids no "Operation Team" that puts the damn thing in production and is woken up at night because the app has crashed and the customer is furious!
As long as you can, keep all hands in one team do it. If you think it's now time to create a new team, think twice, sleep on it for a few WEEKS, speak to me and then maybe we'll consider not doing so. You don't want any handoffs so that no-one can say "my work here is done" before the customer has gotten value out of it.

7. Heartbeat

So you have a customer, a vision, some users, a backlog to work on, people to work with you and roles to fill. Hey, that's shaping up quite well isn't it? To finally give that Frankenstein's Monster life, we "just" need a heartbeat.

In Scrum, we have the "sprint" as a fundamental unit of time. But this idea is not limited to Scrum, we'll talk about this later. The Scrum sprint is kicked off by a planning, closed by a review-retrospective combo and sprinkled with some meetings along the way. Decide on a lenght (2-4 weeks are recommended) and stick to it.

I'd strongly recommend such a hard tempo for multiple reasons:

  • It breaks the project into "chewable chunks"
  • If forces you to think into small "potentially shippable increments" (PSI) and create value incrementally, which tends to prevent over-engineering
  • It forces you to go through the whole project lifecycle every so often. Among other things, this means testing your push-to-production skills, making sure the documentation is up to date, test-proofing the logging framework you put in place and involving the customer to give you feedback about the whole shebang
  • Retrospectives are easy to skip, having a hard beat will makes the argumentation against holding a retrospective less likely to succeed: "at the end of a sprint there is a retro, period".

As I said, you might not be working in a Scrum context. In a Lean/Kanban style, you would be monitoring the throughput of your team and analyzing the so-called "cycle time" and "lead time" of the items through your system. Pick regular interval that suits you, for example: "every 1/6/42 items done" and get on with inspect & adapt.


There's a lot more that could be said, but I think that'll do for a start. Of course, nothing in this list is mandatory and nothing here is a silver bullet. Each successful project had its own recipe. Nevertheless, those 7 points will help you see your product / project differently and who knows, you might even learn a thing or two...

A more practical and Agile / Scrum oriented list might follow (DoD, DoR, CI, Doc, TaskBoards, Communication, Ticketing, Test, Retrospectives, Reporting etc.), but I need to chew on it for a while first.

What do you think? Do you agree with those 7 first points? Anything to add?

And if it does help you, let me know!

Image Source: To do from Nikki Buitendijk (CC BY-ND 2.0)

Comments powered by Disqus