Lightningspirit's Blog

The Agile Initiative Inception

Do you remember the kick-off day for the initiative you’re currently involved?

What about the first meetings where everyone was super excited and in agreement?

That general positive spreading throughout the room, that lovely shiny feeling of a new thing to develop. How awesome was that, right?

Now, take a step back and look where you are today. Do you feel the same way?

Yes? No?

There’s a strong probability that you’re not feeling well with all the struggling, deadlines, misunderstandings on basic concepts, dealignment. Is that so?

Well, that happens a lot. I’d even say every time, and there’s a reason why that happens: it’s because that you, your teammates, your Product Owner, your Engineering Manager and even all stakeholders are different people, each one with they’re own baggage, conceptions, and agreement on what to develop.

You, your teammates, your Product Owner, your Engineering Manager and even all stakeholders are different people

You’re not aligned with each other, conceptually.

I mean, it’s not about you or the Team Lead of the Product not being able to understand or make it clear to everyone. The reason is without proper common ground rules and fundamental processes that’s what you’ll get on big projects.

You’re not able to conceive strategy for big things all along, sometimes you’re not even able to have good previsions on what you’re going to deliver tomorrow by EOD - it’s human nature, and that’s fine! The truth is: it’s all about prevision.

The truth is: it’s all about prevision

The human brain is capable of calculating 20 million billion bits of information per second only spending 20 Watts on average. That’s astonishingly fast! However, that only works on simple daily activities.

So, is there anything we can do to improve prevision? Wouldn’t it be lovely to have a better knowledge of what’s the real deal when developing a new feature?

I believe so, and I think Agile practices, namely Scrum methodology, might be a truth strength beneath it.

But wait, isn’t Agile about small deliverables and consistent pacing without worrying too much on the big picture? In part, it is a bit, but it is also about great communication, better acknowledgment, forecasting, and collaboration.

Welcome to the Agile Initiative Inception

The only purpose of running a session of Agile Initiative Inception is that everyone is aligned and understand the initiative, and that’s it, nothing more, nothing less!

Everyone is aligned and understand the initiative

Shift your mindset

To successfully run an Agile Initiative Inception you first need the change how you, your team and all intervenients think about why it is important to find common knowledge.

The following image is a good way to represent what we want to achieve:

agreement then

Picture borrowed from Agile Warrior

One way to do it is to work with all intervenients from the very beginning envolving them even before this session and to clearly define your problem first.

If you don’ know each other, drink a coffee together, share your ideas and ask for their feedback.

Start from the beginning

Sit everyone together, define a social contract regarding equipment you can use and how to leave the room without interruption, breaks, etc.

Start by presenting an Agenda and what are the expectations for the session. The following is an example of such:

  • Understand the initiative motivations
  • Find your common ground and understand the goals
  • Raise questions, doubts and close previous open questions
  • Assess risks, impediments and dependencies
  • Discover the direction, what is in the scope and out-of-scope
  • What are the next steps? Create action points.

Start with a “Why?”

Duration: 10 minutes

Generally, what you want to achieve is a set of goals that define a vision for the project, which means you can reduce it to a sentence.

All intervenients need to understand who are the stakeholders and the reason behind the initiative.

Scope, out of scope, unresolved

Duration: 30-90 minutes

Once the vision is defined, you advance to the next step in this process where you write down in a big whiteboard or by using post-its what is in the scope and what it is not:

scope out of scope unresolved

After running this step, you’ll come with some barriers about what you want to tackle and what is out of the scope.

Meet your neighbors

Duration: 30-60 minutes

Now it’s time to identify dependencies or points of contact. For each item/topic on scope, know which teams need to be involved and what external dependencies need to be resolved.

Keep in mind that this is only a high-level overview as the details for each item/topic should be aligned in different sessions, such as a User Story Mapping.

Show your solution

Duration: 60-90 minutes

Using the big whiteboard, rearrange your scope and draw your boxes involving everyone and try to include some technical details in it (but nothing elaborated).

Divide the team into small task groups and draw some architectural diagrams taking into account:

  • Existing ecosystem that might be affected
  • Describe what needs to be changed
  • Understand the implications of such changes
  • Drive the discussion to the outcome

Optionally you can decide to do a quick presentation about each part of the architectural diagram and make sure everyone understands what role each component plays in the existing ecosystem.

What keeps us up at night?

Duration: 30-60 minutes

One thing most of the times we forget to discuss is to assess risks we can face on short and long-term during all the initiative lifecycle: from development to general availability.

Start by mapping the risks and drive the discussion for each one to conclude if they worth tackling or not - be conservative in this phase. The recommended maximum time for each topic is about 10 minutes of discussion.

Last but not least, take out the Unresolved ideas and drive discussions for each one like you did for the ones within Scope.

If you can’t find an agreement, place that item in a Parking Lot for further discussion in a different forum and move on to the next one.

User Story Mapping

Now with all the work we did before, we’re prepared to run one or more User Story Mapping sessions where the Product scope is clear, and everyone is ready to deep dive into the user journeys.

Conclusions

The described methodology is a high-level framework to involve everyone during the Product design phase. Whenever you feel you need to find common ground, you should run it.

I think this tool can help teams to define a vision, scope and requirements of an initiative for the next steps and unblock some inconsistencies and miscommunication that sometimes appears during development phases.

If you find this useful or you already used this in your team, please leave a comment below. Share your feedback so others can benefit from it.

Featured image by Max Andrey


Keywords: agile, initiative, forecast improve, team management


Vitor De Carvalho

Written by Vitor De Carvalho, Software Developer, Hacker, Musician, Astrophysics lover, who lives in sunny Lisbon, Portugal.
Follow me on Twitter Github Soundcloud