Behaviors and Culture Can Impair Creating Good Product

When we think culture, we often think about nationality and/or regional cultures. Culture is often a dinner discussion with my wife and friends; it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s ingrained in us.

Last month VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note: I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns About Adoption

  • Lack of Upfront Planning – 34%
  • Loss of Management Control – 31%
  • Management Opposition – 27%
  • Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

  • Failure to integrate people – 34%
  • Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

  • Fear of Losing Control. This is primarily an individual fear; however, it can also be ingrained in the organization. I’ve heard, “If I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth because we generally see everyone’s engagement raise up a notch or two. Thus, more people are involved in making the decisions at the proper levels — hence, scaling the organization.
  • Gate Keeper Culture. Often a subset or product of ‘Fear of Losing Control,’ this is the manager or director who acts as the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder… or where, in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
  • Measurement of Success is Based upon “On Budget and On Time.” Many organizations, especially IT organizations, live in the world where they try only to be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product, either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what, everyone is happier including the development teams.
  • Fear of “What’s My Role?” This is the protectionist behavior where managers and/or team members don’t see a fit for themselves, or don’t find a fit for themselves, as an agile transformation takes place. These team members or managers generally start creating barriers to deflect blame while at the same time climb to the rooftops to shout out about the failures of the team and process. Meanwhile others are looking at the right thing (e.g., product moving out successfully).
  • Victim Mentality. Have you ever heard, “It has always been that way and it’ll never change?” Well, this is the typical response for the person who either doesn’t want to deal with change or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people; then I learned quickly: if you don’t ask, you don’t get. And, if it is something that could have really positive results, isn’t it worth the risk?
  • Superhero Culture. Now don’t get me wrong; I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to over-commit is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project which our ScrumMaster isn’t supposed to know about. Again, hard work is great but we have to respect the concepts of sustainable pace, transparency, and “The Team.” Remember we regularly deliver value.
  • Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role-based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad (or no) rapport between the teams. Role-based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not yet been visible. And Ivory Tower silos are typically, “I’m a Director” or “I’m the Product Manager and you just do what I say.” This never results in teamwork unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits,” then you might have some Ivory Tower silos and are possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to hear about those that not only impacted your agile implementation, but those that impacted delivery of good product.

Posted in Agile Adoption, Agile Development, Agile Management | 2 Comments

Agile and Beyond: A Right-Sized, Value-Rich Conference

VersionOne was proud to sponsor and exhibit at the 4th Annual Agile and Beyond conference on Saturday, March 9th in Dearborn, Michigan.

We talked with many project managers, developers, business analysts and directors about their past, current or future agile aspirations.

The highlights:

  • The vendor space: The exhibitors were placed in the lunch/break area; this was the perfect place to capture attendees’ attention during breakfast, lunch or between sessions. A fully-loaded cappuccino cart certainly didn’t diminish the traffic flow. We’ve been placed in ‘far-away-from-the-action,’ ‘off-the-beaten-path’ locations at many conferences, but this location was ideal for attendee interaction — significant conversations and product demonstrations.
  • The attendees: Some agile events get an influx of job seekers or people with a curiosity to get to know agile. Agile and Beyond delivered practitioners who are living and breathing agile every single day. These were developers and project managers who have worked with sticky notes, Excel, tools (hopefully VersionOne ;) ; they were clearly able to articulate the challenges that hold their team back from consistent agile excellence.
  • The sessions: The VersionOne team didn’t have much time to attend sessions, but a few of the sessions shone.

@mattbarcomb presented: “Building a Learning Organization From Any Level”. Anyone working in software knows that you must always be learning. The pace of change is exhilarating, but stressful. When everyone’s learning, we can share best practices, doing our best to keep all aware of the latest trends and techniques. You can’t learn everything, so why not ‘divide and conquer?’ Matt’s exercises and examples of how organizations and individuals can start learning smarter now through apprenticeship, mentoring, shadowing and more were extremely energizing.

Our team also had the chance to hear @toddkaufman present a talk titled: ‘Failing with Agility’. In a crowd and environment that’s markedly bullish on agile practices, it took some courage to mention missteps. It’s through failure, however, that we learn. Todd was able to share a strong message about not just going around the periphery with agile, but ways to unleash agile’s power of true organizational change.

Thank you, Agile and Beyond, for a wonderful conference; VersionOne is looking forward to next year.

Dan Naden
Community Manager
VersionOne

 

Posted in Agile Adoption, Agile Management, Agile Teams, Scaling Agile | Leave a comment

Top 10 Things the State of Agile Development Survey WON’T Tell You

Every year we publish the highly anticipated results of our State of Agile Development Survey. And every year we see momentum for agile climb, supported by consistent business benefits (faster time to market, ability to manage changing priorities, better alignment between IT and business objectives, blah, blah, blah). ZZZZZZ, right?

I could list out some of the interesting stats here. Or, I could trust you will check them out on your own and instead – use this time to list the Top 10 Things the State of Agile Development Survey Will NOT Tell You:

1. Where to find free beer 24/7? No need to consult a survey for that. Just get a job at VersionOne, where there’s always free (and cold) beer on tap. Good beer, too. Otherwise, you’re on your own.

2. Why did the chicken cross the road? Umm, what chicken? Put the crack pipe down.

3. Who shot J.R.? Ok, so I just realized that many of you might be too young to know WTF I’m talking about. It was a rather lame (but once cool) TV show in the late ‘70s with plenty of drama, cheese, big hair and too much makeup. See Dallas.

4. Why did Superman wear his briefs on the outside of his tights? To this I say, “why not???” Did he need a reason?

5. How many licks does it take to get to the center of a Tootsie Pop? I don’t know about you, but owls kind of creep me out. Especially owls that lick. Why not a kitten, or a baby? And who ever made it that far anyway? Didn’t you just bite into the whole damn thing after a minute or two?

6. Do sheep get static cling when they rub against each other? Sounds like a fun Friday evening to me.

7. If Jimmy cracks corn and no one cares, why is there a song about him? Ha-Ha! This reminds me

jim-gaffigan-happy-and-you-know-it

of a great Tweet I saw the other day from my favorite comedian: “There should be a children’s song “If you’re happy and you know it, keep it to yourself and let your Dad sleep.”

8. Why do toasters always have a setting that burns the toast to a horrible crisp which no decent human being would eat? This is an age-old mystery. Maybe the sick people who enjoy this are the same ones who bake cookies all the way to 17 minutes when the directions read “13 to 17 minutes.” Everyone knows this clearly means no more than 11 or 12.

9. Why do birds have white poop? They don’t know any better.

10. Why anyone is still doing waterfall? Probably the same reason birds have white poop.

In all seriousness, I wanted to know what you think of this year’s results? If you’ve seen previous reports, you’ll notice some of this stuff remains relatively constant every year. But new questions were added in 2012, making this IMHO the most interesting report yet.

We covered the usual suspects plus some new topics, including:

  • Agile Portfolio Management (APM) trends
  • Top lessons learned when scaling agile
  • How teams typically carry out the role of the ScrumMaster
  • Most popular agile methodologies, techniques and tools
  • Things people wish they could say to their company president about agile

Grab the full report now and share it with your team.  Then let me know what you think.

 

Posted in Agile Development | Leave a comment

2 Great Talks on Lean Management & Story Mapping Coming to DC 3/20

If you’re in the DC area, or know someone who is, be sure to mark the calendar for March 20th. You won’t want to miss this great lineup of talks coming to AgilePalooza DC, including these two from our friends at Lithespeed:

“Timeliness of Lean Management” – keynote from Sanjiv Augustine and “Story Mapping in a Nutshell” from Arlen Bankston. Here’s a quick overview of their upcoming presentations.

Timeliness of Lean Management

Agile development methods like Scrum, XP, and recently Kanban have achieved notable success in improving speed to value, reducing waste, and raising customer and team satisfaction. Successful practitioners worldwide have cut development times, improved product quality and reduced engineering cost. Notably, underlying the agile methods are timeless Lean principles, including: focus on customer value, respect for people, and continuous improvement. At AgilePalooza Sanjiv will describe how agile teams in various organizations are implementing Lean management.

You’ll learn the basics of Lean, including its origins in the Toyota Production System, and how to apply Lean to software development with the disciplined practices like automated build-and-test and test driven development. You’ll also see how program-level Lean-Agile PMOs manage WIP, how executive teams use visual control to manage their enterprises, how managers collocate in oobeya team rooms to go to the gemba, and how kaizen teams drive continuous improvement across the organization.

Story Mapping in a Nutshell

Using interactive exercises, Arlen will discuss how to do advanced product and release planning using the simple, but powerful technique called Story Mapping.  This technique has been used by many agile teams to better represent the product backlog in a way that facilitates rapid prioritization based upon clearly articulated stakeholder and business goals.  Participants will see how story maps can be used to efficiently run agile release roadmapping and planning sessions that transparently balance multiple project goals and constraints.

Learn more and register for the event at http://agilepalooza-dc2013.eventbrite.com/

Posted in Agile Development, Agile Methodologies, Scrum Development | Leave a comment

The Realization of Where We Are With Agile

A guest post from Alex Adamopoulos, CEO of Emergn Limited

In recent weeks I have been involved in or privy to conversations with four global financial services companies, a research and publishing company and an airline all talking on the topic of the realization of where they are with agile.

Six companies. All global. All leading brands. All using agile. All at a crossroads with it.

All of these companies have the following things in common, almost to the letter:

  • Agile, more specifically Scrum, has been used in the IT organization for at least two years and in some cases much longer
  • Success using Scrum has been experienced on several projects
  • General acceptance of agile has grown across the IT organization and in all cases people on the business side are now aware of it to some degree
  • A disparate agile team and staffing model exists
  • The business wants more of the benefits from this way of working but none of these companies have gotten enough buy-in or investment to refine the approach that would do make this happen.
  • The realization has set in that even though using agile (Scrum) has provided many benefits worth repeating on other projects, there is stall a gap in terms of standardizing an approach across a wider part of the IT organization

In short, these companies are at an impasse. While their IT executives all see the reasons and the needs to go wider and deeper, their cries are ignored by those holding the purse strings. There is frustration and a sense of “what do we do now?” One these companies openly admitted to having watched much of the good work and output just slip away over the last year or so.

The problem can be explained. Much of the investment that companies have made in agile has really been centered on two specific areas: putting an agile development team in place and/or putting two roles on projects, ScrumMaster and Agile Coach. In defense of these investments, for a long time, this was the standard approach to introducing agile. You would decide to dabble with it, bring in a ScrumMaster if you had a handle on what you wanted to do, or an Agile Coach if you knew you were going into deep waters and wanted more hand holding.

Both these roles would work alongside of your team, in many cases improve the team and the project and victory was claimed. It’s right here where many of the challenges started. Companies often add coaches to other projects and in some cases create an internal agile practice or center of excellence but in effect, it really becomes a way to staff roles on projects. It ends up looking more like a resource management function instead of a well constructed, transformation team that has established an approach focused on outcomes and output not just “doing agile.”

What I’ve described above is still a common approach. What I’m suggesting is something completely different – it’s actually a question: What problem are we trying to solve? That answer means I’ll spend my budget differently and probably not on the things I was originally thinking about. It means I might need to have some tough conversations with senior executives and stakeholders. It means many things will be different if we answer it honestly.

I understand I may sound like I’m making some very general statements and maybe seem even a bit harsh. I’m playing back the conversations of these six companies. So while I definitely know there are many companies that are not in this same predicament, there are many more that are.

This predicament that I’m taking too long to explain is that these companies know with certainty that an agile-minded organization founded on principles that adapt better to change is the way forward, BUT the obstacle to getting there is still helping procurement and parts of the business see that they’re not talking about just another product or service which can be auctioned on the street. Rather, the realization is that just putting coaches and ScrumMasters in place no longer ensures that change will stick and that the company will realize the investment 10 or 100 times over.

One of these six companies is taking steps to correct their journey. After investing in building a global agile development practice, they now see that having a disparate coaching model is becoming counter-productive. Their emphasis now is to help this group develop a standardized (yes, sometimes a bad term to use in the agile community, but it’s proven to be necessary) approach that isn’t tied to a single methodology or model but provides for at least a minimum set of practices and principles that are specific to that organization’s goals. Flexibility is still key, but structure has been lacking for all six of these companies when it comes to delivering a predictable, consistent, high-quality service to their customer.

So it’s not all bleak; it just needs to be called out. Others need to know they’re not in this place alone and that they can take the lessons learned and move this forward with some fresh thinking.

How do they do that?

For starters, all six have voiced or rather acknowledged where they are. While this sounds simplistic and a bit obvious, recognition is the first step to recovery (to borrow a term). Secondly, it takes a bit of courage, but half these companies are rewriting their charter and going to the business to develop a joint vision of what “change” means for the organization.

I suppose that is the ultimate question: Why are we using agile? More importantly, what does change mean for us, not only in IT but across our business? For new ideas that need funding and for projects that we know are critical yet challenged, what are the results we want? It’s from this basis that we can then consider the best approach for our organization.

It’s never “we need agile” – it should always be we need this _____ result/outcome (“fill in the blank”).

Read Alex’s blog

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Portfolio Management | Leave a comment

VersionOne Visits PMI’s Region 5: An Eager Agile Audience

The weather was cold and snowy outside in Charleston, West Virginia in late January, but the atmosphere within the Charleston Marriott Town Center was warm, sunny and full of life. The Town Center was hosting the PMI Region 5 Annual conference.

VersionOne had the opportunity to interact with Chapter Leadership from PMI’s Region 5, covering portions of Kentucky, portions of Virginia, West Virginia, North Carolina, Maryland and Washington, D.C.

We interacted with attendees and had a wonderful time getting to know the other friendly sponsors: GR8PM, a project manager exam preparation company, and Berry Dunn, a full service accounting and consulting firm with experience in a variety of industries.

The attendees were extremely eager to learn about our agile project management tool. We are no longer living in a world where, when you mention the word ‘agile’ to a project manager, he would give you a quizzical, puzzled look. Project managers now lean into conversations about agile, demonstrating anticipation and readiness to master this new mindset to deliver value to organizations.

The arrival of the PMI-ACP certification and the continued project manager interest in the CSM certification shows that agile and project managers are getting to know one another.

Thank you to Brian Cochran and the rest of the leadership team for a fantastic Region 5 annual conference; they were responsive and accommodating in helping us reach our goal of bringing agile education to project managers.

We were thrilled to discover that many of the attendees held positions of influence within their organizations: Director of PMO, Senior Project Manager, PMO Lead.

The conversations with attendees were both deep and insightful. Many non-IT/software project managers wanted to hear of use cases, best practices for how agile can be introduced into the world of construction, manufacturing and transportation.

We look forward to the next opportunity to interact with the great folks at PMI’s Region 5.

Want to learn more about agile as a project manager? Check out these resources.

Dan Naden
Community Manager
VersionOne

 

Posted in Agile Adoption, Agile Methodologies, Agile Project Management | 1 Comment

Where Are We Going Out After the Meeting?

I haven’t posted for quite a while, mostly because I’ve been spending a *ton* of time with
some really amazing clients.  What a great year!  Teams are really starting to move forward with those aspects of agile that really make a difference.  The theme for the year has migrated from “How can we *do* agile?” to the more appropriate and infinitely harder “How can we *be* agile?” This is the goal for 2013, for sure.

As I’ve been working with teams, I’m starting to uncover certain aspects of teamwork that really make a difference.  Some of these are things I mentioned in my previous musically oriented blogs, such as the often discussed cross-functional nature of team members, or the willingness to pick up an instrument that isn’t necessarily your specialty.  Now I want to talk about having fun.

One of the amusing aspects of playing in a jazz group is how much of our conversation ends up talking about going out.  We usually say that rehearsals will last until “beer-thirty,” or discuss where we are going after the rehearsal.  Now, it isn’t about alcohol, and not everybody goes.  The reason we do this is that we actually *like* to spend time together, not just working.  And yes, a rehearsal really is work.  It’s enjoyable work, but then again so is programming.

OK Steve, how does this apply to agile teams then?  I’m glad you asked me that.  The teams which I have seen be the most successful are the teams who actually spend some time out of the office together.  Not just crazy team building exercises (kudos to the VersionOne PS team for soundly beating our Services team in WhirlyBall) but also just casual get-togethers.  Getting out of the office to just let your hair down is a great way to get beyond the cold, stark realities of the office.

Some of the teams I’ve been working with have developed this kind of a cadre at several different levels.  I’ve seen it not only with specific teams, but also with some of the more successful management teams.  They have developed a non-verbal communication style that makes it easy for them to understand and support each other, as well as their teams.  And I’ve seen them in no uncertain terms call each other out, asking hard questions and getting just as hard answers.  No hard feelings, just good honest communication. I have found that teams who are able to go out from time to time are able to communicate better. They develop a common frame of reference and are able to relate on a more comfortable basis.  This comes in handy when they need to start communicating things that aren’t necessarily good news.  Or asking someone to step up if they are falling behind.  These communications shouldn’t happen while out; but being comfortable with each other makes it easier to have those conversations back at the office.

Now, a final word on this.  You can’t force this.   You can’t tell team members, “I expect you to go out on your own time once a month and have fun.” What you can do is support it and provide an atmosphere that says it’s OK.  Start with something simple like telling the team that if they want to go have lunch together the next one is on the company.  Or maybe at the end of a grueling planning meeting say, “Hey, who wants to go grab some hot wings?  I understand it’s trivia night tonight.”  Make sure it’s casual, make sure people who choose not to go don’t feel like they aren’t part of the team anymore, and for heaven’s sake HAVE FUN! 

Posted in Agile Development | Leave a comment

Agile Capacity Calculation – Part 2 of 2

In the first part of this two-part blog, I presented two methods for agile capacity calculation:

  • Method 1: Capacity is not required to be estimated or calculated.  This is an idealized  and the simplest method.
  • Method 2: Capacity is only roughly estimated (in number of hours) using a small number of parameters.

In this second part of the two-part blog post, I present the third and last method for agile capacity calculation, i.e.,

  • Method 3: Capacity is precisely calculated (in number of hours) using a fairly comprehensive, and extensible and customizable set of parameters.

The capacity to do actual hands-on work for each team member is calculated considering a number of parameters, such as:

  • Number of weeks and workdays available in a sprint:   For example, for a 4-week sprint, there are 20 workdays (assuming 5 workdays per week and no days lost due to company holidays).   If a sprint starts later than Monday of Week 1 and ends earlier than Friday of Week 4, there will be less than 20 workdays for the sprint.  As an example, if the sprint starts on Tuesday of Week 1 (perhaps Monday was a heavy snow storm day and the company was closed), and ends on Thursday of Week 4 (perhaps Friday was set aside for Sprint Review and Retrospective), the sprint will effectively have only 18 workdays.
  • Number of company holidays scheduled during the sprint time-box: If company has 2 holidays during the sprint time-box, the number of workdays in that sprint will reduce by 2, which will also reduce the individual and team capacity.
  • Personal vacation or paid time off for each team member: For example, if a team member is planning to take 3 vacation days in the upcoming sprint time-box, his capacity will reduce by 3 workdays (and the team capacity will reduce too by that amount).
  • Full-time vs. Part-time membership on the team:  If a team member is not a full-time member of the team, but is planning to work only 50% of the time on the project, his capacity will reduce by 50%.
  • Time needed to prepare for and attend daily Scrum meetings.
  • Time needed to do general e-mail and phone calls, and attend company or non-project meetings.
  • Time set aside for contingency.
  • Any factors that will reduce the capacity of a team member, such as:
    • Support work for the previous release of software
    • Preparing the backlog for the next sprint while the current sprint is going on (so-called two-level Scrum pipeline)
    • Training new member of a team
    • Self-training to increase cross-functional skills

Although this is a seemingly comprehensive list of factors to consider in calculating the capacity, it is not an exhaustive list.  It may need addition, deletion, revision and customization to suit the needs of your organization.   It may seem that Method 3 requires too much computational effort.  This computation, however, is done by an Excel-based template, giving you an almost instant capacity number.

I have developed this Capacity_Calculator template to allow you (ScrumMaster or Project Manager for an agile team) to do the capacity calculation for each team member and the entire team very quickly.  You may customize this template to suit your organizational needs.  Its Instructions worksheet summarizes how to use the template for your needs.

  • In the Capacity worksheet of the Capacity_Calculator template, replace example persons with your team’s members.
  • Add columns needed for additional members of your team, along with formulas copied from other columns.
  • You may also consider any Guest Members on your agile team, who are responsible for very specific tasks for a limited duration.
  • During the Sprint Planning session, ScrumMaster enters data in Pink cells of the Capacity Worksheet for team members.
  • The Capacity worksheet will calculate the Capacity of each individual and the Team Capacity at the start of a sprint.
  • ScrumMaster may insert comments in Pink cells where he has entered data for his team.
  • Enter the individual capacities at appropriate place in VersionOne tool.
  • Once capacities for all team members are calculated using this template and the Sprint starts, the Capacity worksheet should NOT be changed.

As the Capacity_Calculator template is based on Microsoft Excel, it can be used to do what-if exercises to see the impact on capacity by changing various parameters, such as the % availability of each member, planned vacation days, and by changing factors that reduce or change the capacity of each individual, etc.  The template has evolved over the last three years with feedback from its use by over 50 agile teams, with many refinements based on that feedback.

The calculated capacity number is used to provide guidance to the agile team in terms of how much work (stories or features, and defects) it should plan to undertake for the upcoming sprint.   This was explained in Part 1 of this two-part blog series.    Please refer to Part 1 of this blog for details.

If your team is a well-jelled agile team with demonstrated stable velocity, and all assumptions required by Method 1 are in place, you should use Method 1 as described in Part 1 of this blog.   A well-jelled team with stable velocity is a very desirable goal.  If you can indeed use Method 1, you really do not need to calculate the capacity.   However, if Method 1 cannot be applied, you will need to use either Method 2 or 3.

As Method 3 comes with a Capacity_Calculator template, I strongly recommend using Method 3 over Method 2.  Although Method 2 estimates the capacity quickly, it provides you only a rough estimate of capacity if you have historical data available on hands-on work in a typical 8-hour day or 40-hour week.

Method 3 calculates capacity of individual team members and the entire team precisely and very quickly (using the Capacity_Calculator template), allows you do what-if exercises, and provides complete transparency for capacity calculations to all team members and management.   I have seen many teams and their members are surprised to see lower than expected capacity number coming from the Capacity_Calculator template; however, the template allows them to understand why the capacity number is low (and its specific value), and how it can be increased in a realistic way.  This transparency on capacity calculation enables an honest conversation among management and team members on how to balance the capacity and the workload, which is even a bigger benefit of the Capacity_Calculator template.

Here are two examples of conversations I have observed in agile capacity planning done by the teams I have trained and coached.

  • Agile Team A calculates its capacity and finds that it is 30% less than the workload (prioritized list of features and defects) that its product owner wants the team to deliver in the next sprint.   The team realizes that adding new members to the team is not a viable option to raise the team capacity for the next sprint.   The team members discuss (facilitated by the ScrumMaster) how they can increase team capacity by 10% by taking a number of steps (increasing the allocation of time of two part-time team members for the sprint, reducing planned vacation days for two other team members, etc.).   Team members and product owner discuss how to reduce the workload by approx., 15% by taking two lowest priority features and one lower priority defect out of the sprint scope, and by reducing the scope of one of the features.  The team capacity is now only 5% lower than the planned workload; the team feels comfortable with that situation and decides to proceed with the sprint.
  • After the capacity and workload are roughly balanced (brought within 5% of each other), agile team B looks at the individual team member’s capacity and individual workload by using VersionOne tool.  Sheryl (User Interface developer) is found to be overloaded, while Tim (Java developer) has excess capacity.   Sheryl and Tim discuss how some of Sheryl’s workload (simple UI development) can be completed by Tim with guidance from Sheryl.  They both realize that Tim is not going to be as productive as Sheryl is in UI development work as that is not his primary expertise.  In the spirit of a cross-functional agile team, he volunteers to pitch in with guidance from Sheryl.   This load balancing helps reduce Sheryl’s work overload to some extent, but she is still overloaded.   No other option is feasible.  The team discusses with the Product Owner and they agree to take two UI-intensive features out of the sprint scope, and bring in a non-UI-intensive feature currently in the release backlog into the sprint scope to facilitate proper load balancing between Sheryl and other team members.

In conclusion, use Method 1 if you are a well-jelled agile team and all assumptions required for Method 1 are met; otherwise, use Method 3 with its downloadable Capacity_Calculator template.  Let the capacity planning effort guide the conversation among team members and the product owner to complete the sprint planning process.

Part 1 – Agile Capacity Calculation

 

Posted in Agile Development, Agile Management, Agile Project Management, Scrum Development, Scrum Methodology | Leave a comment

No Resolutions, Please

As I sat with my strong-willed 5-year-old on Christmas Eve, she prepared to write a letter to leave out for Santa Claus. “What should I write?” she asked me, this being the first year she could actually pen her own missive.

How about starting with “Dear Santa, I’ve been a good girl this year?”

“No! I can’t write that, because I haven’t. I don’t want to lie!”

The concern in her voice was palpable. It seems our repeated hints when the song “Santa Claus is Coming to Town” had finally taken hold (you know, ‘…He’s gonna find out who’s naughty and nice…’). She wasn’t willing to risk lying to Santa on this the very evening he was coming with his bag of presents. Although her behavior had yet to be significantly altered, she was quite aware of her shortcomings.

Much like the 5-year-old who recognizes room for improvement, we all can point to an area or two in which we’d like to perform better. While the New Year is typically a time for making resolutions, I find that resolutions tend to be short-lived and, therefore, a waste of time.

A continuous process, though, of selecting and focusing on one of your team’s shortcomings is a proven way to improve. Whether it is ensuring a good set of acceptance tests are defined *before* beginning a new story, creating more complete automated unit tests, firming up environmental issues, or following through on retrospective commitments, agile teams will generally have some set of improvements that are known, but not yet acted upon.

Not your team? Well, then here’s a place to start: hold a retrospective. Your team is sure to uncover some opportunities. Still drawing blanks? Really? Maybe you need to make it more fun. Try one of the Innovation Games such as Speedboat to get your group into the brainstorming mood.

In contrast with the young child who does not yet possess the willpower to change her actions, I encourage you to move beyond the “knowing” stage and get into the “improving” stage on one top item. Just one. Any one. When you have that one licked, pick another. Then another. Before you know it, your team will be well on their way to even better results.

And remember: you don’t have to wait for a New Year to start improving. Make it a continual process and feel free to start any time… like now. And please don’t call it a resolution.

Posted in Agile Adoption, Agile Development, Agile Teams, Iterative Development | Leave a comment

Agile Capacity Calculation – Part 1 of 2

Capacity of an agile team is an important measure that should be used to inform the team how much workload it should undertake during its sprint planning meeting for an upcoming sprint.  If the capacity and workload are not in balance, then the team members should have an informed conversation with the product owner on how to achieve the balance.

I will present three methods for capacity calculation:

  • Method 1: Capacity is not required to be estimated or calculated.  This is an idealized  and the simplest method
  • Method 2: Capacity is estimated (in number of hours) using a small number of parameters.  This is an approximate but quick method for estimating the capacity of an agile team for a sprint.
  • Method 3: Capacity is precisely calculated (in number of hours) using a fairly comprehensive, extensible and customizable set of parameters.  This is an accurate method for calculating the capacity of an agile team for sprint.  The actual calculations are done very quickly using an Excel template.

I present Methods 1 and 2 in this first part of a two-part blog series.   I will present Method 3 in the Part 2.  At the end of the Part 2, I will offer recommendations about which method you may select for your use, based on your agile team’s specific situation.

Method 1: Capacity is not required to be estimated or calculated.

Let us consider the simplest (and somewhat idealized) method of a well-jelled agile team; i.e., a team whose members have worked together as an agile team for several sprints in the past and have achieved stable velocity.  For example an agile team has worked during the last 4 sprints, and demonstrated measured velocity in a narrow range (within plus-minus 10%) such as 19, 21, 20, 19 story points.   In this example, the average velocity of the team (averaged over the past 4 sprints) = (19+21+20+19)/4 = 19.75 = approx. 20.

If the same team (exactly the same members) are planning to work as a team in the next sprint, and the number of work days available in the next sprint is the same as that in the last few sprints, and no team member is expected to be pulled off the project for any significant effort, then the agile team in this kind of ideal scenario can comfortably plan 20 story points worth of work in the upcoming sprint.

In this method, the actual capacity of the team for the upcoming sprint need not be estimated or calculated due to several idealized assumptions are assumed to be met, such as:

  • A well-jelled agile team has achieved stable velocity; and the average velocity measured over the past 4 sprints is a leading indicator of the estimated velocity for the upcoming sprint
  • The same well-jelled team will work in the next sprint; i.e., exactly same members will continue
  • The number of work days available in the next sprint is very close to the number of work days in the past few sprints; i.e., the next sprint will not have an unusual number of company holidays, no team member is expected to take long personal vacation, and no team member is expected to lose capacity due to other assignments outside the sprint work
  • The technology platform will stay the same for the next sprint (no change from the previous sprint)
  • No new domain knowledge by any team member is required for the next sprint

Method 2:  Capacity is estimated in number of hours using a small number of parameters.

This method is applicable when one or more assumptions justifying Method 1 is not true or is at least questionable.   If one or more of the following conditions are applicable, Method 1 should not be used:

  • The agile team is not a well-jelled team yet; it has experienced erratically changing velocity sprint by sprint in the past.
  • The agile team composition is likely to change for the next sprint from the previous sprint; this will certainly change the team dynamics and team productivity.
  • Capacity of the team for the upcoming sprint is expected to be different from the previous sprint due to upcoming holiday season, summer or winter vacations, etc.
  • Team members are expected to work on a different technology platform during the next sprint.
  • One or more team members need to learn and apply new domain knowledge for the next sprint.

In this kind of scenario, we cannot take the average past velocity as the leading indicator of the estimated velocity for the upcoming sprint.  We need to estimate the number of hours available for the team to do actual hands-on work during the upcoming sprint.   In this method, a simplified model is used by considering historical data in the organization for typical “hands-on time” in a given 8-hour day (if this data exists and is available).  Based on historical data, the team may use 60% to 80% of the 8-hour day as the time available to do actual hands-on work.  The remaining time (40% to 20%) is taken away for general email and phone calls, company meetings, preparing for and attending daily Scrum meetings, etc.  So each full-time team member is estimated to have 4.8 hour to 6.4 hour per day (or 24 to 32 hours in a 40-hour work week) to do hands-on work.   As an example, if an agile team has 8 full-time members and uses 4-week sprints, it will estimate its capacity to be 8 x 4 x 24 = 768 hour (assuming 60% hands-on work), or as much as 8 x 4 x 32 = 1,024 hours (assuming 80% hands-on work) for the upcoming week.

Note that this is only a rough estimate of the capacity of an agile team, as it is based on a single parameter (% of time available to do hands-on work, typically 60% to 80%, based on organization’s historical data).  If historical data is not available, some organizations use a guesstimate number (say 75%) based on anecdotal evidence, or its sense of comfort level with this number.

The estimated capacity number is used to provide guidance to the agile team in terms of how much work (stories or features to be implemented, and defects to be fixed) can be planned for the upcoming sprint.  For example, if the team capacity is estimated to be 800 hours, its estimated work should be close to 800 hours; the team may exceed its capacity, but by no more than 5%; i.e., in this example, estimated work should not exceed 840 hours.

An agile team now needs to estimate or calculate the number of hours of planned work based on its prioritized sprint backlog.   The effort for each story and defect needs to be estimated in number of ideal hours (not elapsed hours).  This can be done at the story or defect level by the team based on its collective knowledge of the work involved.  Alternatively, each story and defect can be broken down into tasks and tests, each task and test is estimated in number of ideal hours, and those estimates are rolled up to get an estimate of the effort for story or defect in ideal hours.

As Method 2 provides only an estimate of the capacity based on a single or small number of parameters, it is only an approximate measure.  If you need to precisely estimate the team capacity in number of hours based on a comprehensive set of parameters, you will need to follow Method 3.  This method will be presented in the second-part of this two-part blog post.

 

Posted in Agile Development | Leave a comment