Category Archives: Uncategorized

May 22, 2012

The Birth of the “Agile Project Leader”

By Stephanie Davis

With 8 months of full-fledged Agile under our belts here at Valpak, it was high time for me to update the job description for my team of Project Managers.  The point being to not only match the day-to-day activities of the job with the written description, but also to best reflect where we are at in our Agile transformation and our continued commitment to the cause.  With little help from the Internet (that’s right … this was mostly created from scratch!), I created a new job description for “Agile Project Leader” and re-titled my entire team.

  • “Agile” for our commitment to living the values and principles established by The Agile Manifesto,
  • “Project” because we view things best through our project lenses,
  • And, “Leader” because we strive to truly lead and not just manage.

Since I was hard pressed to find any real world examples of job descriptions for “Agile Project Leader”, I figured I’d share mine with the community (that’s you!).

Next up … I need to update my own job description too!

JOB DESCRIPTION: AGILE PROJECT LEADER

Summary:

Leadership of technology-focused projects and teams relying on Agile values and principles.  This position assumes the role of ScrumMaster, Kanban Lead, and/or Project Manager depending on the work at hand. The focus of this position is on delivering value over meeting constraints, leading the team over managing tasks, and adapting to change over conforming to plans.

Essential Duties and Responsibilities:

  1. In the Project Manager role, leads complex initiatives across multiple functions and teams by planning, directing, and coordinating to the project objectives with consideration for risk.
  2. In the ScrumMaster role, facilitates the Scrum process of planning, daily stand-ups, reviews, and retrospectives with team and Product Owner and proactively removes impediments to progress.
  3. In the Kanban Lead role, facilitates the Kanban process with team and stakeholders and proactively removes impediments to progress.
  4. Leads and contributes to the decision making process and facilitates conflict resolution.
  5. Embraces, coaches, and evangelizes Agile values and principles across the organization and in the community.
  6. Defines and refines Agile metrics to understand team performance.
  7. Works with management and other Agile Project Leaders to continually identify and implement organization-wide process improvements
  8. Performs related work and additional duties as needed or required.

 Education/Experience:

Bachelors degree in a technology field or related degree.  Minimum 4+ years of project management experience and 1 year experience with Agile software development methodologies, namely Scrum and/or Kanban.  Additional years of directly related relevant experience may be substituted for the educational requirement.

Qualifications:

  • Strong analytical and problem solving skills
  • Detail-oriented and highly organized
  • Strong presentation and communication skills
  • Self-motivated driver able to make progress despite obstacles
  • Strong servant leader able to lead and work with multiple diverse roles and personalities
  • One or more related certifications such as Project Management Professional (PMP), PMI-Agile Certified Practitioner (PMI-ACP), or Certified ScrumMaster (CSM) preferred.

4 Comments   |  tags: , , , | posted in Uncategorized

April 20, 2012

An Agile Light Bulb Moment: Forming Projects Around Teams

By Stephanie Davis

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!

Leave a comment   |  tags: , , | posted in Uncategorized

April 10, 2012

Accountability to Sustainable Pace and Work/Life Balance

By Stephanie Davis

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!

1 Comment   |  tags: , | posted in Uncategorized

March 27, 2012

Talking Work Podcast: Goin’ Agile!

By Stephanie Davis

Give a listen to my guest spot on the Talking Work podcast on goin’ Agile.  Enjoy!

http://talkingwork.com/2012/03/27/episode-21-going-agile-and-effectively-communicating-with-stakeholders/

Leave a comment   |  tags: , , | posted in Uncategorized

March 16, 2012

The Power of the Backlog

By Stephanie Davis

The power of the backlog is incredible in a Scrum world.  If stories are the promise of a future conversation, then the mighty backlog can certainly start, end, or even influence a conversation.

The backlog can start a conversation … “Do you have it on your backlog?”

The backlog is a conversation starter when something new is identified as being a valuable enhancement to a given product.  Of course, value is generally subjective, but in this case, value is in the eye of the Product Owner with input from all the various stakeholders.  Maybe this sort of conversation is started from an executive, a stakeholder, the team, or even the true end user themselves.  Regardless, the backlog is that Scrum-sacred home where cool, hopefully valuable things go to wait until their story is planned into a sprint (and become part of the sprint backlog).  Even if the story never gets planned into a sprint, there is some satisfaction to the person that came up with the idea that it has been considered and is “on the backlog”.   As a ScrumMaster, I know that I feel satisfied when the Product Owner says, “Yep, I’ve got that on the  backlog already”.  If the idea is truly proven to be the next most valuable thing to work on, it should be planned into an upcoming sprint.  If not, it had it’s time on the backlog and maybe it falls off or is killed someday.  Call me sadistic, but I actually enjoy the killing of the occasional low-value backlog item.

The backlog can end a conversation just the same … “That’s not on our sprint backlog. Let’s backlog it for now.”

The backlog is a conversation end-er when something is brought up that isn’t on the current sprint backlog.  It’s amazing how much of an impediment (possible) future work can become if allowed to run wild.  In the old days of traditional waterfall project management, this was called scope creep and typically handled like a change request under whatever change management policy may have existed.  In most cases, meetings were called, the change was assessed, guess-timates were given, and friends or enemies were made as some change committee yeah-ed or nah-ed it.  All of that took time, time away from the team working on the approved scope of the project; more time in some cases than others depending on the degree of the change and the corporate bureaucracy in place.    Under Scrum, the power of the backlog makes clear what is in the current sprint backlog and what should be “backlogged” for a future sprint.  This means the team remains focused on the current sprint.

The backlog influences conversation … “We might want to add another developer to the team. I’ve got a 2 year backlog built up!”

The backlog influences conversations day in and day out throughout the life of the product.  One might even say, the backlog speaks.  The backlog says …

  • How much technical debt still exists for a product (especially if you religiously capture bugs and such in the backlog).
  • How much value remains to be implemented for the product.
  • Whether continued investment in a product or Scrum will continue for 1,2, 3 or however many months/years.
  • All that the team accomplished and the value delivered in past sprints.
  • And, so much more!

So, next time you overhear things like “it’s on the backlog”, “backlog it”, or “it’s not on our sprint backlog”, just remember that it’s all in the power of the backlog.

1 Comment   |  tags: , , , , , | posted in Uncategorized

March 9, 2012

I’m an Agilephile: Contagious or Nauseating?

By Stephanie Davis

I’ve been told my enthusiasm for Agile is contagious. I assume that some may find it nauseating.  Yes, I am a tried and true Agilephile!

After 16 years in the project management profession, it’s easy to get stuck in a rut.  Such is the case with any career I suppose … however, not me, not now!  I’m actually more passionate about project management now than I’ve ever been and much of that is due to Agile.  Embracing Agile has really been invigorating to me.  Right now, I’m having the time of my work-life helping the IT organization at Valpak with their Agile transformation.

I see it this way … An Agile revolution is taking place across the world. Agile project management is like the lead singer in the rock band. Traditional project management is like waiting in line at the DMV.  The PMBOK has always been like a set of rules to be followed.  With Agile, it’s all about values and principles.  Almost like a religion, people can become spiritual about Agile by embracing the values and principles and even apply them to traditional projects.

So, maybe I’m contagious to some and nauseating to others.  I’m an Agilephile!

1 Comment   |  tags: , , | posted in Uncategorized

March 5, 2012

Agile Limericks

By Stephanie Davis

Besides green beer, what better way to celebrate St Patrick’s Day than with a few fun limericks.  With that in mind, I’ve created some Agile limericks for you to enjoy.

As you may recall, limericks are short, witty (sometimes raunchy) 5-line poems with an AABBA rhyming pattern.  Since this may be the first time ever attempted (combining Agile and limericks), please go easy on me.  Feel free to add your own Agile limericks to this post as well.

A Team that has tired of sprints,
Might be sending their PO a hint,
That pace is a matter.
Sprints keep getting fatter.
A pace to sustain the intent.

If the Team had gone with their gut,
They wouldn’t be stuck in a rut.
To accept such a story,
Made the sprint pretty gory,
And next time it won’t make the cut.

As for value, this story had none,
But the stakeholder thought it’d be fun.
With no value in sight,
No one put up a fight,
And never that story got done.

A team member says in a fright,
“An impediment is cause for our plight!”
The ScrumMaster did smell
and let out a yell,
“I’ll squash it with all of my might!”

There was a Product Owner from Naboo,
Constant backlog grooming she’d do.
But groomed it was right,
To her Team’s delight,
And never a story poo-poo.

1 Comment   |  tags: , , , , , , , | posted in Uncategorized

February 28, 2012

A Scrum Board Is Worth A Thousand Words

By Stephanie Davis

Last week, we had three tours in three days around here.    Yes, I said “tours”.  “A tour of what?”, you may ask.  A tour of our Agile transformation!  Now, understand you-me that tours are typically reserved for our state-of-the-art manufacturing facility (not a plug, just a reality).   At first, I didn’t realize there was much of a show to be had with all our old cubicles and dingy carpet, but apparently I was all wrong.  The tours were such a hit that we’re now making a video!  Yes, that’s right, a video… an Agile transformation video.

We gave tours to three different groups, two stakeholder groups and one VIP.  Each tour began at our local copy of The Agile Manifesto where we explained the values and principles that guide us.  Then, the tour moved into our beloved Scrum Pit (a.k.a., “The Pig Sty”) where we used the 9 Scrum Boards to visually eplain how Scrum works.  Last but not least, we walked the tour groups through the bullpen areas for 6 of our 9 Scrum teams to demonstrate the open collaboration environment we’ve established.

The mere fact that we had three tours in three days really demonstrated two things to me: 1) Our leadership is proud of what we’ve accomplished with our Agile transformation in just 8 sprints and 2) we’ve really done well by way of “visible information radiators”.  Like the old saying, “A picture is worth a thousand words”, a Scrum Board is worth a thousand  words too!  Our towering walls of magnetic whiteboards with index cards seemingly-chaotic, yet intentionally-placed  really seemed to leave quite the impression with our tour groups.  I know now that having handed them a document or an illustration or shown information buried in some tool wouldn’t have nearly the impact.  Our visible information radiators worked!  At the time of the tours, we were mid-way through the 8th sprint across 9 Scrum teams, and progress (or lack thereof) was clearly visible within a 360° view of the Scrum Pit.    I guess what I’m getting at here is simple … When your hand gets tired of writing story after story or task after task and you’ve got paper cuts on both hands, just remember that a well-constructed, well-maintained Scrum Board is the ultimate visible information radiator and worth a thousand words.

Leave a comment   |  tags: , , , , | posted in Uncategorized

February 24, 2012

Story Points: What’s The Point?

By Stephanie Davis

So, what’s the point of Story Points?  9 Scrum teams and 8 sprints into our Agile transformation and it seems that some still struggle with the proper use of Story Points, a common relative estimating technique.  That said, I put together the following tips on this topic to help my teams (hopefully they will be of help to your teams as well).

  1. Story points are a relative measure of effort to done, NOT complexity, NOT priority, NOT sequence.  Something that is highly complex might take very little effort to complete and might be considered 1 or 2 or 3 story points. On the other hand, a 13 point story might be worth further decomposing into smaller, independent stories.
  2. A common technique for story points is the use of the famous Fibonacci sequence of 0 1 2 3 5 8 13, 0 being hardly any effort and 13 being the most effort.  Commit it to memory! Say it frontwards, backwards, forwards until you make it a habit.  Or, make a game of it and get some Planning Poker cards for your teams.
  3. Story points must always be established before tasks and task hours.  You can do them as part of backlog grooming, at the start of your sprint planning, or even negotiate them over e-mail, but never-ever do tasks and task hours before you establish story points.  If you do, you basically negate the benefit of your relative estimating technique.
  4. After establishing story points for stories within a given sprint, you should be able to group all the 13’s and the 8’s and the 5’s and so on and they be of relatively the same effort.  Make a point of thinking about it that way during your Sprint Planning.  Furthermore, you can use the task hours you come up with in Sprint Planning to make sure it all jives.  If you have a 13 point story and a 3 point story and both have just 6 hours of tasks then it is questionable as to whether you got the story points right or if you’ve considered all tasks.
  5. Story points are determined by the Team (based on all that has to be accomplished to meet your definition of done).  It’s not about just analysis or just QA or just coding.  The ScrumMaster and the Product Owner do not determine story points.
  6. There is indeed such thing as a zero point story if it’s something that the team has relatively no effort for.

The point of Story Points is to someday stop having to think about all those tedious task hours.  If you know your team’s velocity of story points over time, you can use story points to determine what can nicely fit within a sprint.  For instance, I know that some of my teams at full capacity are 40-ish story point teams.  With that knowledge, the Product Owner can select 40-ish points of stories for the team to work on in any given sprint.

1 Comment   |  tags: , , , | posted in Uncategorized