Tag Archives: project initiation

An Agile Light Bulb Moment: Forming Projects Around Teams

It’s great when you have a light bulb moment.  It’s even better when you inspire a light bulb moment in others.

The other day, I had the pleasure of speaking with several managers from another Tampa Bay company about Valpak’s Agile transformation.  I use the word “pleasure” thoughtfully because I genuinely enjoy talking to others about the Agile transformation taking place here at Valpak.  It’s a great story and I love to share it!   Anyhow, apparently how I explained our project initiation process resulted in a light bulb moment for them, or at least that’s what the guy said.  They are moving towards Agile and seeking advice and experiences from other companies having recently transformed.    So, let me explain what I explained to them and you can decide if it’s a light bulb moment.

From whence we came …

Used to be that when a project was initiated, a team would be formed around the project.  In most cases, the team members were already assigned to multiple projects 30% here, 50% there, and so on just waiting for their phase (analysis, design, development, QA, etc.) to start in the waterfall process.  Team members were not necessarily dedicated, just committed.  So, with project plans changing as they do, a team member would typically end up being pulled in multiple directions, reporting to multiple masters, across many projects all at the same time.  From a people perspective, this is not a fun place to be (remember, “multitasking” is the new 4-letter word).  The result was low morale from all the project whiplash going on.

… to where we are now.

Today, under our Agile structure of 8 Scrums and 2 Kanbans, we have naturally experienced a shift in our project initiation process.  Now, when a project is requested, we evaluate the request based on the existing Scrum and Kanban teams and we form the project around the teams.  Sometimes this means breaking up the project to fit the vision and/or skill of the teams.  So, as opposed to forming a team around a project, we are now forming a project around teams.

Let’s take a look at a real world example.  Most recently, we enhanced our Valpak.com website with photo galleries on some of the business profile pages.  This project was ultimately broken down into multiple stories across three teams:

  • One team to upload the photos into our order entry system,
  • One team to store the photos in our content management system, and
  • One team to display the photos on the web page.

While coordination and collaboration across teams can not (and should not) be under-estimated, this beats a team of 30 people working over 6 months in a waterfall process any day.  By forming the project around the teams, team members are able to remain focused and dedicated to their product vision, thus resolving the project whiplash and leading to improved morale.

You may ask, “What if a project is requested that doesn’t fit the vision and/or skill of any of the Scrum or Kanban teams?”  Easy!  It becomes an investment decision.  Is the company willing to invest in a new Scrum and/or Kanban in order to fulfill the request?  This could mean hiring new people to staff new teams and/or pulling people from existing teams to form a new team.  Either way, it’s a leadership decision as to whether to invest in the new idea or impact the investment in an old idea.  In fact, we’ve actually had this happen.  We didn’t start out with 8 Scrums and 2 Kanbans.  Investment decisions were made over time that led us to where we are today.  It’s all about adapting.  It’s indeed Agile!