Monthly Archives: April 2012

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!

Advertisements

Accountability to Sustainable Pace and Work/Life Balance

One of the 12 Agile principles that we should all be holding in high regard states …

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The team is accountable to their sustainable pace.

Sustainable pace should be on all of our minds on Sprint Planning day.  The Product Owner brings forth 20 stories and the team negotiates them down to 15 with sustainable pace and their velocity range in mind.  For those teams that handle production support, we all know it can be the wild card.  During the planning session, we mitigate this risk by having team members predict their personal sprint capacity (50%, 80%, etc.), taking into account non-sprint meetings and a predictive measure of support.  Also, we can further manage this by only working on support that our Product Owner deems immediate work.  Any other support can be backlogged and planned into a future sprint. Now, should all hell break loose in the support arena, some stories may be dropped or some stories might not meet the team’s definition of done.  No one should take it personally.  No one should feel like they are disappointing their Product Owner or their ScrumMaster.  Besides, there’s always the next sprint!  Story points and velocity are just numbers.  They are not used to grade a team, but rather intended help a team plan.  These sorts of discussions around the sprint goals and support should be had each and every day with the team, the Product Owner, and the ScrumMaster as part of the daily Scrum.

Bob Hartman provides a balanced take on sustainable pace:

http://www.agileforall.com/2009/07/24/new-to-agile-work-at-a-sustainable-pace/

The person is accountable to their work/life balance.

So now, a bit about work/life balance … Your ScrumMaster and functional manager don’t necessarily know if you are pulling ridiculous hours to pull off a story.  If you’re at home working off hours, we can’t easily observe that.  If you send me an email at 8pm a night, I don’t know if you just had a quick thought or if you have negatively impacted your work/life balance.  We all need to speak up on this topic and engage in constant dialogue with management.  The occasional sacrifice is appreciated, but shouldn’t be considered your team’s sustainable pace.  In fact, by working continuous overtime and not making it highly visible to your team, Product Owner, and ScrumMaster, you risk upping your team’s velocity, which just sets unrealistic expectations.  That said, work/life balance is a personal thing.  There are many happy “workaholics” in the world (I might just be one of them).  My threshold is different than your threshold which is different than the guy next to you.  We are all personally accountable to our own work/life balance!