Don’t have a strong product owner?

In this post we explore why a product owner is needed, and how we can ease the burden on the customer as well as the product owner by setting expectations and speaking in language the customer understands.

Recently received this email from a fantastic gentleman who runs an Engineering team in a wonderful part of the world (let’s call him Bob). Bob is facing some challenges with the business side of the company who is his customer:

  1. Business wants hard deadlines for completed functionality. However they do not provide clean and concise scope / acceptance criteria. Further, they struggle with the concept of iterating to a solution and just want it now.
  2. Lack of understanding from the business about the level of effort required to be a successful Product Owner. The business is the customer and the customer can not articulate their vision (perhaps they believe we should read their minds).
  3. The business can not focus, going from one thing to the next before Engineering has had a chance to complete the first item.

It’s great to get emails like this as it just reminds me we’re all struggling with many of the same challenges. For instance, I’m having a similar conversation with another fine gentleman (Steve) in another part of the world, at another company. The key difference is that Steve is on the other side of the equation. Steve is the business side that is struggling with an Engineering team which can not deliver.

I wanted to share the two sides, as told from different people at different companies, as they are useful in helping us overcome these shared challenges.

So, Steve is on the business side and can’t understand why the Engineering team just doesn’t deliver what he wants, when he wants it.

Steve and I walked through an exercise where I asked him for all of the requirements he wanted in his “2.0” release. He rattled off several things, and then started out on some more. I asked him why they were important, what he was trying to solve with each.

All the while his Engineering team is struggling – they hear “go this way”, “no, go that way” and never feel like they have clear direction or a vision. So, I continue with the gentleman (who should be wearing a PO hat, although is a business owner so “doesn’t have the time”) and ask him to order the top three things he wants, out of that long list of ideas. Steve does so.

I want to confirm with him – “are you sure these are key to 2.0?”, I ask. Steve says that yes, that is what he wants for 2.0. I explain that he hasn’t mentioned the UI/UX rewrite the team is currently working on, nor has he mentioned X, Y, Z from the teams backlog. “So why are they working on all this stuff which is nice to have and not valuable?” I ask.

Steve hasn’t noticed that he is pushing the team in a different direction every day. He hasn’t noticed that the vision has not been set, or communicated.

In that situation, and I’m sure this is similar to Bob’s, there is a lot going on. The business folks have a million things they want, but there is only one thing top of mind at the time you speak with them. So it looks like they have no vision. I asked Steve to write the release blog for his 2.0 – what would he like it to say, how would he pitch it to his clients, etc.

This was a forcing function to get Steve to consider the scope for his 2.0. It was a release planning exercise in language he understood – a blog post, not a backlog.

Now I’m not sure how successful this approach will be at every company, for every team. I do hope that it provides the business side an understanding of what is involved in being a product owner and setting a vision. Of course you can also use this as a tool to define scope for a release – if/when the business comes back to Engineering and adds something to the list you can respond with “didn’t we agree last Tuesday to do X, Y, Z first, and then move on to other items?”. Don’t let agile be an excuse for less discipline, more WIP, and less value being delivered.

Be agile. Be smart. Help the business side, or your customer, have some discipline and get value early and often. We need to educate our customers as much as we need to educate ourselves.

Got thoughts or suggestions for Bob or Steve? Share them in the comments below.

Agile 2013 – that’s a wrap!

Nick had a grand ‘ole time in Nashville for the Grand Ole Oprey Agile 2013.

IMG_5757

Take a look at his posts highlighting the sessions he enjoyed most. If you haven’t been already, make sure you grab a ticket for next year, the conversations in the hallways are worth the price of admission alone!

Technical Debt meets Agile

Agile Coaching

Agile Metrics – Velocity is not the Goal

 

Roles and Responsibility, Essential to a High Performing Agile Team

There are three key roles for every Agile team: Product Owner, ScrumMaster and the Team. And, of course, we also have the stakeholders – our customers, managers, board of directors, etc. We’ll take a look at these roles and their various responsibilities and then we will explore how these people gel to form a high performing agile team.

Product Owner

The Product Owner is the proxy for the customer. They are available to the team during the course of their working day to answer any questions about the customer – for instance, the team may want clarification around the problem the customer is trying to solve, or their motivation, or when and where they experience said problem. The Product Owner is a necessary role in every agile team as it ensures that the Team has a subject matter expert on hand and can get their questions answered promptly to avoid being blocked.

Ideally the team would be co-located with the customer and could ask them questions directly. Often this is not the case, which is unfortunate. However, even when the Team is co-located with the customer the role of Product Owner is still necessary.

The key responsibility of the Product Owner is to paint a vision for the product and order the product backlog. They take all of the input from the customer and work with the customer to identify the highest value problems they have – ordering the backlog from highest value to the customer to lowest. Clearly we want to focus our effort on delivering the most value to the customer as soon as possible.

ScrumMaster

The ScrumMaster is another essential role for a high performing agile team. The ScrumMaster has a number of responsibilities and they have a place in both Scrum and Kanban teams – the term KanbanMaster is not in common parlance, although the responsibilities are the same.

ScrumMasters are often considered servant leaders1 as they put the priorities of the Team before their own. They help the Team overcome blocked work, defend the team from scope change, maintain the reports to measure Team progress and facilitate the agile ceremonies such as planning sessions, daily standups, demo’s and retrospectives.

A ScrumMaster may, for instance, help a team write out their Definition of Done and Working Agreement, and help the team stay accountable to themselves for these definitions which they own. Discipline is key to a high performing agile team, to any high performing team, and so the role of the ScrumMaster requires great discipline too.

Team

The Team themselves have responsibilities as well. Ultimately everyone in the Team, including the Product Owner and ScrumMaster, are responsible for the deliverable – if the quality is not up to scratch the team has no one to blame but themselves.

An agile Team works as a cohesive unit – not a loose grouping of individuals. It is important that the team strives to become cross-functional, if they are not already. Being cross-functional helps the Team avoid being blocked and assists with the flow of work ensuring they deliver value to the customer consistently and frequently, enabling a positive feedback loop.

The Team estimates work on the backlog2 to give them confidence that they can meet the sprint commitments (Scrum) or to allow them to measure cycle time with greater accuracy (Kanban). This drives predictability for the Team, and may give the Product Owner the confidence to provide delivery estimates to the customer.

Delivery is another key point, if the Team commits to deliver then they must do so. To do anything else could harm the trust of the customer. Clearly there are unforeseen circumstances that arise and impact this from time to time – these should be the exception and should be explored in a retrospective. When the team commits they also commit to stick to the Definition of Done and Working Agreement that they own.

Chickens and Pigs

Above we’ve looked at the ‘Pigs’. There are also the stakeholders, the ‘Chickens’. The Chickens have responsibilities too. But first, why do they get these terms? Think of bacon and eggs for breakfast (yum!), the chicken is involved by providing eggs while the pig is committed by providing bacon3.

So, what are the stakeholders responsible for? Customers in particular are asked to explain their problems, not merely the first layer but the root cause of their problem. The team will help the customer identify this root cause and work to address it. The customer is also responsible for providing input to the Product Owner around priorities.

Finally, stakeholders should not disturb the Team directly with new work requests, instead they should speak with the Product Owner to get these requests entered in to the backlog.

High Performance

When these roles and responsibilities are clearly defined by the Team people will not abdicate their responsibilities, will work together better, and will hold one another accountable for delivering. The underlying ethos of Agile is to be constantly looking for opportunities to improve, and this is no different. If you find that one person is better suited to being the Product Owner – perhaps they have built a good working relationship with the customer – then feel free to try switching roles.

Clearly defined roles and responsibilities give the team structure to perform at their capacity, minimise disruption, and focus on getting work done.

Now, what’s stopping you from being a high performing team? Follow @VelocityCounts to be notified of future blogs.

Enjoy this essay? React on Twitter:

  1. Is Your Scrum Master a Servant Leader? []
  2. Why do high performing Scrum teams use story point estimation? []
  3. Wikipedia: The Chicken and The Pig []

Commitments & Conscious Business

Five frogs are sitting on a log. Four decide to jump off. How many are left? Five, because deciding is different than doing.

One of the fellas at Twitter brought this to my attention last week. It is from Conscious Business. It made me sit up and take note. It made me think about a teams ability to commit, and to deliver.

The author of Conscious Business, Fred Kofman, goes on to write:

Decisions are worthless … unless you turn them into commitments.

Incidentally, the book comes highly recommended. Add it to your list.

Eliminate Free Radicals – A Path to Scaling Agile in the Enterprise

You might remember from chemistry class that a molecule can exist without a paired electron, making them highly reactive. Molecules fitting this description are considered “Free Radicals“. What your professor may not have told you (mine certainly hadn’t) is that Free Radicals (or Radicals as I like to refer to them as) also exist in human form and unlike their scientific brethren, they often appear in clusters, especially within large organizations. While they may play an important role to science, I’ve always placed the human version at the top of my list of reasons preventing Agile from scaling within large enterprise.

Characteristics of a Free Radical

I have some great news for you. Free Radicals are extremely easy to recognize within your organization. Here’s a list of characteristics and mannerisms to watch for:

  • Every task they represent to the organization is urgent and a top priority
  • They do not use a consistent medium to communicate information
  • It’s not easy to recognize any direct contributions they make to the organization
  • They don’t want to take time to learn about the methodology you work within (e.g. Agile)
  • They submit requests just short of the due date
  • They echo communication across many channels (e.g., email, IM, phone, etc)
  • They are quick to offer compliments privately, but never in public forums
  • They are indecisive
  • They are often the center of conversations with conflict
  • They wander the hallways with lemon water in hand (a tangental observation)

Free Radicals can Squelch Agile Adoption

When I speak or meet with Agile coaches or any executive looking to adopt or grow their Agile deployment, I begin with a cautionary statement about Radicals. Their meer presence, no matter the number, can quickly squelch Agile adoption. Therefore, you must develop a plan to insulate yourselves (see below). By exerting their own chaotic manor of work, Radicals squelch Agile adoption by:

  • With Scrum teams – Insisting that changes be admitted to active Sprints (e.g., backlog promotion / scope change mid-Sprint)
  • With Kanban teams – Insisting that their items be expedited and change SLA course
  • Not accepting deliveries against their agreed upon definition of done
  • Frequently interrupting team members
  • Forcing exemptions to be from an accepted list
  • Contributing to the delay of requirements definition
  • Refusing to obtain status updates from systems or boards, preferring them from people
  • Breaking cadence (our internal rhythm)
  • Contributing to friction and causing frustration

Insulate and Scale

Ahh, recognize them now – don’t you. Worse, you realize that Radicals are all around you, possibly looking over your shoulder right now? Relax, they don’t like to read from a far, especially articles with the word “Agile” anywhere in the title. There are three simple ways to insulate your teams and reach scale – and even better, a simpler way to remember them. You WOW them. Walls, Obstacles and Warfare. I developed this strategy years ago and it’s something that I’ve continued to practice and introduce to hundreds of Scrum teams operating within enterprise-size organizations.

Walls

I’m not talking about the physical here. Unfortunately building codes and the such require that you have adequate doors and means of egress. Admittedly a slower life form, Radicals have evolved to a point where they have opposable thumbs and can navigate simple obstacles quite readily. As an Agile organization, everyone on your team needs to be comfortable saying no to requests which challenge the methodology in which you work or jeopardize the working agreements you have in place with other departments / divisions. For humans, it’s often hard to say no and Radicals can make this harder and outright uncomfortable at times. You need to have a common redirection in place, one that everyone on your team understands and feels comfortable using. The key is that everyone must respond in the same manor and provide a near-identical response. It won’t work unless this is the case. An example of this redirection might be: “Sorry, we are in feature freeze right now, so I can’t make additional changes without jeopardizing the project schedule. You need to talk to <INSERT The Big Boss HERE> if you want that change made”. Radicals will hear this and then check with the next team member, and the next, and the next… and so on. They are looking for a weak link in the chain. If they receive the same response, take my word for it, they will go away.

Obstacles

I’ll be the first to admit, Radicals from time to time will have a valid reason for causing an interruption or asking for an exception, etc. When this occurs, we still need to steer them towards a less-chaotic manor of introducing the new work stream. In other words, let’s not just stop what we or everyone is doing just because they are in possession of a valid item of work. As an Agile organization, we need to have a well described process of how we accept work, what details are required before we will evaluate, how long it will take us to respond, how we will respond, etc. Effectively we are sharing the teams working agreement with other parts of the organization. The process of handling exceptions needs to be clear and available to all, so making it part of the working agreement makes sense. The working agreement is a living document that your team visits as part of your retrospectives to see if there are opportunities to modify and strengthen the contents. An example of an obstacle might be the fact that your team will not accept any User Interface (UI) items without prior receipt of PO sign-off against User Experience (UX).

Warfare

Let me guess, you skipped ahead to this section didn’t you? If you did, it’s alright, but please go back and read Walls and Obstacles first. Ok, welcome back! The first two-thirds of this strategy are highly effective techniques at protecting your Agile deployment and teams from Radicals, they should be employed first and then we move to the last stage of our strategy. It’s time to rid your organization of Radicals. Trust me, it can be done. Here are some simple and proven methods to handle the job:

  • Every month, make it a goal to take a Radical to lunch. At lunch: (a) explain Agile and how your teams have adopted from 10k feet and (b) let them know in no uncertain terms, that the better they follow the process, the more work will get done for them (e.g., bribe them).
  • When a Radical follows the process correctly (listens to Walls, navigates Obstacles), go out of your way to recognize their act and do it in a public forum. Reward positive behavior and discourage Radical behavior. (Yes, the same applies to puppies).
  • Publish a list of work items completed, grouped by Radical in descending order. Display this list in a public location (e.g., Wallboard). Peer pressure will help foster non-Radical behavior.
  • If Scrum, then invite them to join a sprint review / demo, give them a front row seat to view potentially shippable product first.
  • If Kanban, them join your team when reviewing team activity. Demonstrate how the team pulls items through stages of completeness.
  • Offer to help a Radical organize and map their teams chaos into an Agile framework. Maybe show them Scrum or Kanban applied to their world. I’ve converted dozens of Radicals using this simple technique.

In other words, the best way to rid your organization of Radicals is to help them grow their knowledge of the way your teams have elected to work. By doing so, you are helping to retrain them and making their job and others more enjoyable in the process.

Does your organization suffer from Free Radicals?  If so, how are you handling them? We’d like to know, share your perspective in the comments below. Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.

 

Why do high performing Scrum teams use story point estimation?

There are two common approaches to estimation in Scrum teams: story points and ideal hours. Ideal hours is taken as ‘given what we know today, how long would this story take to implement?’ if everything went according to plan.

It turns out that us humans are pretty terrible at estimating. For example, is this story, with this acceptance criteria, going to take three or four hours? If you’re familiar with this situation you’ll agree it can be hard to tell.

As the team wants to give the client a pretty accurate idea of when they will deliver the story they ask for more information upfront and we find ourselves in the situation where we are defining everything upfront to get a slightly more accurate estimate. This is waterfall people, not what we want!

Estimate = Guess

If we remember one key thing, it is this: an estimate is a guess. That’s it people, an estimate is a guess, it is not a commitment, it is not a firm delivery date. The more time we spend talking about a story to clarify it the closer we’ll be to an estimate in hours that reflects the required number of hours to implement that story. Unfortunately we won’t be any closer to actually delivering it!

Given humans are bad a estimating we can use a relative approach to estimation. For example, what is heavier, 7000 elephants or 1 jumbo jet?

Enter Fibonacci

The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’. This is a similar problem to the ideal hours described above.

Further to that, reaching consensus on a story point estimate, and getting clarity on acceptance criteria is made easier with the help of planning poker. With planning poker we hand out a set of cards with the fibonacci sequence (1, 2, 3, 5, 8, 13, 21) on them to each member of the team. As the team reads out a story and the acceptance criteria each team member picks a card from their deck and leaves it face down on the table. Once everyone has selected a card the whole team turns over their cards and compares the estimates.

This has two benefits, it is a quick way to estimate and the team has a fruitful discussion about the story and acceptance criteria.

Finally, when a team uses story points for estimation there is no confusion with the customer as to this being a commitment – what would committing to ‘5 story points’ actually mean? As there are no ideal hours attached the customer is under no illusion as to the time involved. Thus freeing the team from an artificial deadline.

Want to learn more about high performing Scrum teams? Sign up now to be notified of the next blog post or podcast.

Why Agile teams want t-shaped people

On Scrum teams we often speak of ideals. While these may not be immediately attainable by the team they are things a team should strive to attain as it will assist them in becoming a high performing team. One of these ideals is a T-shaped person.

A t-shaped person is one who has breadth in a number of areas, and depth in a few. This allows that person to pick up work that, for example, includes front-end and back-end technology. The t-shaped team member may not be a wizard on the API’s, although they’ll be able to get by.

T-shaped people complement Agile teams

If we’ve got a team of t-shaped people then we’ve got breadth as well as depth in a number of areas. The team members will complement one another.

For example, we have Bob who is a t-shaped person with front-end and back-end experience. Sally is the API wizard though. How does this work in practice? Bob may pick up a story that requires an extension to the API, and he will write that. Sally may provide a code review or have included some points in the acceptance criteria to guide Bob. Ultimately they are working together to deliver value to the customer.

Cross-Functional Teams

A team of t-shaped people, each with different skills and specialities, enables team members to complement one another and form a high performing team. Teams with these cross-functional members, another way of saying t-shaped people, are higher performing as they have less internal bottlenecks and contention for one person’s time.

Of course the final benefit is that the team no longer has a single point of failure (SPOF). Should Sally leave the team then Bob has sufficient knowledge to continue on.

Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.

Is Burnover Preventing your Team from Achieving Consistent Velocity?

Burnover.  Another name for Stories or backlog items that are incomplete at the end of the current Sprint and fall into a subsequent Sprint.  Call it what you like, but if you want to reach your Agile Nirvana, then you need to develop better recognition, techniques for handling, and methods of prevention.  If not, then you risk introducing frustration, finger pointing and even issues with team morale.

Does this happen to others?

Absolutely.  It occurs more frequently than one might think.  No matter the experience level of a Scrum team, Burnover will occur.  For teams and organizations early to Agile, this is quite a common outcome and can hinder adoption.  I’ve witnessed many situations where Burnover was sited as an example of why Agile wouldn’t work within the organization and why they had to fall back to <insert another non-effective methodology here>.

What Causes Burnover to Occur?

Good news, it’s real simple.  Most of the time Burnover is your fault!  When I say “you”, I mean your Scrum team (the collective you).  For whatever reason, your team wasn’t able to deliver against your commitment.  The three most common causes that attributed to Burnover are:

  1. Overcommitment – This is the result of fairly classic human behavior.  As humans we want to help.  We want to sign-up for more, always.  It’s how we are wired and actually a very important and helpful behavior, but one that requires some reigning in.
  2. Misestimation – Estimation is a art and one that frankly I’ve struggled with in the past.  It requires technique, practice and a good deal of patience in order to perfect.  Experience and conscious measurement will help you get better with this.  It’s very important to recognize that certain team members will be better at this than others or gaining consistent velocity can prove difficult.
  3. Impediments – Stuff happens.  We are advancing product and technology at such a fast pace.  There are many moving parts, teams are collaborating and integrating – and because of this we often uncover surprises.  Sometimes these impediments prevent forward progress and result in Burnover.

During your retrospective, it’s important to assess each Burnover Story or backlog item, classifying it as one of the categories above.  Knowing the source will better help you prescribe a remedy.

How to Properly Handle Burnover?

Because this will happen, you best know what to do with Burnover Stories or backlog items.  First of all, don’t ignore Burnover or sweep it under the rug.  Regardless of how you feel, ignoring or hiding will only increase frustration and prolong your teams ability to achieve consistent velocity.  Here’s a quick five-step guide on how you should handle Burnover:

  1. Because the Story or backlog item was incomplete, it’s Story points do not count against the Sprint.
  2. The Story or backlog item needs to be moved into a future Sprint or into the backlog.  You shouldn’t make the assumption that it should automatically move to the next Sprint.  Consult your Product Owner and team to find out if the remaining tasks (assuming some had been completed) are still higher priority than other backlog items.
  3. Opinions vary sharply on this, but personally I prefer to “clone” each of the incomplete tasks for an incomplete Story to move to the next Sprint or into the backlog.  This way, we can report against tasks that were completed within each Sprint.  Some tooling will let you track and record this without the need to clone.
  4. Your team will need to review the estimates assigned to each cloned task to ensure that the original estimates are still accurate and the remaining time will need to be reset.
  5. Your team capacity for your subsequent Sprint with the newly added Burnover Stories or backlog items will need to be adjusted.

Tip:  I like to color-code, tag and/or label Burnover Stories and backlog items, so they can be quickly filtered from the active list of committed items within a Sprint.  It’s good to keep a watchful eye on these in their subsequent Sprint, so we don’t repeat and push forward into additional Sprints.

Tips for Preventing Burnover

Impediments aside, you can prevent most Burnover from occurring in the first place.  Prevention starts with historical analysis of your past Sprints.  When coaching teams, I’ll typically build a quick scorecards or something I call a “blame pie“.  It’s a simple pie chart that  assigns historical totals (output as percentage) against the three types of Burnover (Overcommitment, Misestimation, and Impediments).  Using this simple chart will help you focus your attention towards some corrective actions.  

Let’s assume for a moment that your blame pie indicates that the largest percentage of Burnover is attributable to Overcommitment.  In this case, then as a team you need to decrease Stories and backlog items being committed to each Sprint.  While that’s fairly obvious, what I typically see teams doing is guessing at the frequency in which to dial back their commitments.  The method that I find works best, is to have your team commit to their historical average, less the historical average Burnover.  Repeat until you are delivering against 100% of your commitments.   

What if your blame pie indicates that your largest percentage of Burnover is attributed to Misestimation.  In this case, you may need to perform some additional analysis.  To grow your teams estimation skills, you need to find out the types of Stories and backlog items where misestimation is occurring.  Once isolated, look for patterns and find a way to describe or personify the Stories or backlog items along with actions your team will take when they come across something similar in the future.  For example, maybe you find a Story that was “Way too large” and really should have been broken into multiple smaller Stories.  Develop a “Way too large” persona for this Story and describe the characteristics and the action of breaking the Story into smaller portions.  Or maybe you find a task that is not very common, but always takes your team longer than expected because they forget how “Uber complicated” the details are hidden within the task.  Develop a “Uber complicated” persona for this task and make sure you indicate that the estimate should always be higher than the initial value assessed by the team. Once you have a series of persona’s, make sure you publish them in a manor where it is easy to reference during your planning / commitment meetings.

It’s unlikely that Impediments are top on your historical blame pie.  Not to say it doesn’t happen.  I have come across this on rare occasion.  True impediments are difficult to predict and therefore prevent.  However, I do have several suggestions for how to deal with them and will discuss this in greater detail during a future post.  For now, let’s have you focus on reducing and ultimately eliminating Overcommitment and Misestimation from the mix.

Does your team experience Burndown?  If so, what are you doing to mitigate?  Please share your experiences via comments below or tweet@VelocityCounts.

Enjoy this post? React on Twitter:

Planking and its Impact on your Agile Team

New Scrum teams may find meeting their sprint commitments hard, it can be awkward at first! In this post Randall explains what planking is and how to avoid it.

I’ve been an avid hiker since my 8th birthday, the day I got my first new pair of hiking boots. Ever since, if I have time and a trail to hike, I’ll make a go at it. By 15, I had hiked one-third of the Appalachian Trail, which totals 2,200 miles (3,500 km). I trekked North-to-South, a stretch from Mt. Katahdin located in Maine all the way to Maryland. I’ve hiked nearly all of the major ranges in North America, including my favorite the Philmont range located in New Mexico. Early on, while hiking with a good friend and lifelong mentor Yiao-Tee, I learned a very valuable lesson that not only applies to the activity associated with hiking, but one that I’ve carried forward and applied to many other personal and professional activities in my life. The lesson was: to keep a consistent pace, a continuous rhythm only stopping for physical and biological necessity (e.g., shedding / adding layers, hydrating, avoiding danger, or other must-have biological functions). This lesson came as we were ascending above tree line and he saw that I kept stopping every quarter to half mile, insisting that I was gased and needed to rest. Yiao explained that this behavior was more mental than physical. My mind was telling my body to stop and not the other way around. It was in my head. I listened and out of respect, I acknowledged – but I’ll admit, I thought he was wrong.

Fast Forward – Agile Coach

The Company:  Iconic Automotive Company
The Project: Rebuilding the legend of a muscle car in modern day
My Title: Drive fast and take chances (Agile Guy)

At the time, Agile was a very new concept. Ink on the Manifesto had barely dried. With a strong background in Lean Manufacturing and XP, Agile stuck. I’ll go as far as saying it made more sense than any software or product development methodology I had previously used. Locked away in a private warehouse with an incredible team of engineers, we began re-imagining the dream of our Father’s and Grandfather’s generation. The soft click of a key, grind of the starter engaging, the pulse the intake valve gasping for air and fuel, metal on metal as the piston compressed this mixture, a short volt and finally combustion! Sound from the exhaust that would wake neighbors or let friends know you had arrived. Ahh, the muscle car. This was now our dream to conceive, but the catch was we needed to produce working results in 18 months, roughly half the time of standard vehicle production (concept –to- launch). This was a fixed date project, with commercials, marketing and the like all lined up. There was no slipping and no turning back.

What’s Wrong with Us?

We discovered quickly that meeting our Sprint commitments was proving to be more difficult than designing and building a car. The car stuff was their job to figure out. Mine was to figure out why we were failing our plans. Our team was running two week iterations which fed into one month increments and then upstream into project phases. While staring aimlessly at our paperboards and daily burn-down charts fashioned from the back of empty pizza containers (big on hiking, bigger on recycling), a pattern emerged. It’s a pattern that many years later I coined “Planking”. It’s easy to spot and was right there all along, but I overlooked it.

Example of an agile team planking, shown on a JIRA burndown chart

The image above is a burn down chart taken from a project being tracked within Atlassian JIRA. The image depicts Planking, where there was a 4.5 day period of time with zero Stories being completed.

The Discovery

At a varying point in all of our Sprints, I noticed there was a period where no team members were completing Stories. It ranged between 2-4 days, but always present. 29 superstar engineers slowing down at nearly the same point in time each Sprint. None of the pauses were associated with impediments.

I discovered through a series of experiments that our team was the cause of the Planking. Their minds were telling them they needed to pause, break stride and slow momentum. Although everyone had a valid reason for not burning their particular issues during the periods of time, the reasons boiled down to “excuses” that satisfied their want/desire to stop and pause. The team wasn’t underestimating effort, they were Planking.

Prevent Planking

Once discovered, I brought the group together and explained the findings. I mentioned what Yiao had taught me while hiking as a child. In an effort to prevent, we evolved our process and made the following changes:

  • Instead of a Pizza box, I plotted our burn down chart on a large concrete wall using bright sidewalk chalk. We opened our morning Standup by reviewing the burn down as a team. Transparency and awareness of the chart proved incredibly valuable.
  • Instead of pulling Stories from our committed Sprint in order of Business value, we began each Sprint by working on the most complex Stories (where possible). This “eat-the-frog” pattern allowed us to work forward through each Story with the feeling that we were gaining momentum (as the Stories decreased in complexity). I’ll cover this concept in more depth during a future post.
  • I drew a large circle on the bottom of the warehouse floor, just beyond the threshold entrance and in the center I put the number of days since our team had last Planked. The entire team was forced to view each morning as they began their day, reminding them of the challenge we had put behind us.
  • We heckled our colleagues during the morning SU (stand up). Anyone who didn’t burn in a 24 hour period was forced to lean a large 2x6x6 piece of lumber (our version of a plank) up against their desk, almost like a flag indicating they hadn’t burned.

Has your team experienced Planking?  If so, I’d like to hear about it, share your experience in the comments below or tweet @VelocityCounts.

Recommended Reading for New Agile Engineering Managers

It’s a common situation. You’re a kick-ass Engineer and you have just been tapped on the shoulder for a promotion to an Engineering Manager, an “EM”. It means your VP has recognised the great work you’ve delivered, the contribution you’ve made. Congratulations!

At this stage you are probably a bit overwhelmed with questions from team members, the training sessions from HR, and dealing with upcoming performance reviews. Perhaps you’re just trying to get software out the door.

Well we want to get you up to speed quickly, and to help you start getting the maximum velocity from your agile team. So VelocityCounts has put together a list of blogs and books that you should take a weekend to read through. No doubt you’re really busy at present, being a new EM and all. Trust us, taking the time to read over this material is going to pay dividends over the coming months.

If you’re in the situation where you are preparing to become an EM this is a great list to give you some insight. However, don’t be afraid to say no to a promotion – some of the greatest Engineers make the worst EM’s, conversely some of the best EM’s are terrible Engineers. Remember, for every agile team we’re trying to work to peoples strengths. If being an EM isn’t for you let your boss know that you would prefer to go back to coding – it’s okay, they will understand1.

Managing Humans – Michael Lopp

Michael Lopp has had Engineering Manager stints at Netscape, Apple and Symantec. Exposure to a broad range of companies in Silicon Valley and beyond have given him plenty of insight into how to manage humans, more specifically, engineers. Get a taste for Managing Humans by reading one of Lopp’s earlier blogs, Managing Nerds.

These are fun to read in the morning – you’ll arrive at the office with a fresh perspective, and a smile.

Scrum Roles and Responsibilities – Agile Developer Notes

You’re now heading up an agile team. You are an Engineering Manager. Where does that place you? Are you a ScrumMaster, or more of a Product Owner? Perhaps today you are wearing both hats – ideally, that should stop.

Have a read of this and help your team identify the various roles and ensure everyone is aware of their responsibilities. It will make your life a whole lot easier!

The Principles of Product Development Flow – Don Reinersten

Still regarded as the original and the best when it comes to flow based software development. Recommended by Dave Thomas of Bedarra Research Labs every time I see him at any Agile event – Dave is a fanboy and so am I.

Flow details the approach commonly referred to as Kanban. An approach to software delivery based on the flow of work through the value stream, as opposed to timeboxed delivery as in Scrum. A great read and useful for Scrum teams too – you’ll pick up some gems and become a ‘Scrumban’ team.

What is this DevOps thing, anyway? – Patrick Debois

Patrick is the father of the DevOps movement, having kicked off the first DevOps Days back in 2009. DevOps is a movement to bring people closer together, to encourage collaboration between Engineers and their counterparts in Operations. You can’t deliver software without the folks in Operations so it makes sense for them to understand you, and for you to understand them. This also leads to an extension of the ‘Definition of Done’ to delivery to customers – no more checked in to master, on to the next task.

Read about DevOps, and recognise that it has evolved significantly since these early days, but that the premise remains the same – get out of your seat, use your two feet, and collaborate with others. Works wonders for interacting with other teams too!

Scaling Software Agility – Dean Leffingwell

Dean guides Enterprises in their adoption of agile practices. While this may not be of interest to you right now it will come in handy as your company grows.

 

Know of a great blog or book we’ve missed? Let us know.

  1. The Peter Principle: Why Things Always Go Wrong []