Tag Archives: project management

The Three Fundamental Principles of Agile Estimation – The Third One Will Surprise You!

You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation.  This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques.  The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved.  There are three fundamental principles of Agile estimation:

Principle One: Collaborative

Agile estimation methods are collaborative.  This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort.  Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates.  Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.

Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem.  Teamwork and groupwork are based on this concept.  This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.

The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person.  This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort.  This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders.  Another way of stating this principle is that no individual can be punished for a bad estimate.

Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated.  This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.

Principle Two: Relative Estimation

Imagine you are shown a glass bottle with some water in it.  You can see the water sloshing around.  Someone asks you, “how much water is in the bottle?”  You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.”  Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity.  In both cases, you are doing a relative estimate of the amount of water in the bottle.  You are comparing the amount of water to a known quantity.

Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?”  If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum.  You have no basis for comparison.  You might take a wild guess, but it is just that.  Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is.  But those cases are, again, relying on our inherent ability to see relative differences.

So instead of ignoring this capacity, in Agile estimation techniques, we leverage it.  When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work.  The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units.  For example, it is common to use “points” when estimating the effort for Product Backlog Items.

When doing relative estimates it is very important to ensure we are comparing “apples to apples”.  Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done!  If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.

This last point is subtle, but important.  If you have already done something, you know much more about it.  If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it.  By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.

It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).

Principle Three: Fast

In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates.  Whoa!  Why is that?  Because estimation is waste.  You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building.  Therefore, both Agile and Lean concur: do your utmost to eliminate that waste.  There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)

In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast!  Really fast!!!  Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.

There are really only two modestly good reasons for doing estimation in an Agile project or product:

  1. Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
  2. Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.

As a business stakeholder, one can do a simple mental exercise.  Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?”  Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results.  If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).

Bonus Principle: We Suck at Estimating

Most people doing estimation in traditional project management try to measure in units like person-days or dollars.  There is no doubt that these units are useful if you can get good estimates.  However, most of the people doing estimation are fundamentally and irredeemably bad at it.  How do I know?  Because they are not wealthy… and have thereby proven that they cannot predict the future.  If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth.  Given that, it is fruitless and wasteful to try to get better at estimating.  Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now.  Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What is Scrum good for?

I have worked with a lot of people, teams and organizations over the last 8 years helping them to adopt Scrum and I have seen some interesting patterns about where Scrum works well and where it doesn’t work so well. I wanted to share my observations to see if they correlate with what other people are experiencing.

So first off, I want to describe what I mean by Scrum working well:

  1. Teams using Scrum are obviously high-performance teams whose business results are at least 4x that of normal teams.
  2. The organization in which Scrum is being used experiences a change in culture to become more team oriented, more value oriented, and more customer oriented.

So now I can describe where I have observed Scrum to work really well:

  1. When an organization (or team) is in deep trouble and willing to admit it adopting Scrum seems to be a catalyst for creating a new culture, process and team environment where getting out of trouble is possible. This is Scrum for Crisis. The “willing to admit it” part is extremely important as I have worked with two organizations where the “deep trouble” part was obvious to me as an external person, but in both cases management and staff did not seem willing to admit the depth of their crisis and in both cases Scrum failed to act as a catalyst to get them out of trouble. In this use of Scrum, sometimes resolving the crisis then leads back to complacency and Scrum fades away.
  2. Small growing organizations that have no existing formal processes for development can use Scrum as an effective way to maintain their high-performance without getting burdened in bureaucracy. In this case, it is important to note that they are _already_ in a high performance state and their struggle is to maintain that while at the same time growing. I’ve worked with quite a number of small organizations where all they need is the CSM (plus maybe one or two days of coaching) to adopt and maintain Scrum. I have also worked with small organizations that were _not_ already high performance and Scrum has not typically worked to bump them up to a high-performance state.
  3. Pure new product development where a single strong Product Owner can be identified who has the authority to make product decisions independently of anyone else (including product budget decisions). By “pure new product development” I mean that neither the individual team members nor the team as a whole have any responsibilities outside of the product work – there is no “fractional allocation” or “resource levelling” across projects or products. The strong Product Owner is critical to success with Scrum and must understand the principles of Scrum as well as the mechanics of being a Product Owner.

I have also seen Scrum be inappropriate and not lead to the results I mentioned above:

  1. Management teams. It seems like Scrum could or should work for management teams, but it appears that managers have too much of the following problems to be able to use Scrum:
    – operational responsibilities (non-creative, non-problem-solving work)
    – urgent, legitimate interruptions (e.g. an escalated customer issue)
    – real commitments to events or projects that are calendar based (e.g. a management off-site)
    – ego: they don’t want to follow an apparently rigid process or they are always happy to make exceptions for themselves
    Again, one might imagine that Scrum _should_ work to help resolve these issues, but unfortunately I have never seen it able to do so in this context.
  2. Small teams/projects. Scrum is too heavy for teams less than 5 people or for projects shorter than 2 months in total duration. Those numbers aren’t meant to be hard and fast, but when I’ve seen small teams/projects attempt to do Scrum they _always_ end up breaking lots of the rules partly because they can and partly because they must. That said, some folks have created “Personal Scrum” and other variants. I’m not sure if we as the Scrum Alliance officially recognize/endorse those variants.
  3. Purely operational work. There just isn’t enough creativity/problem-solving to make the Sprint an appropriate process element, nor the Product Backlog an appropriate organizing mechanism. I have seen some operational environments get some benefit from doing regular retrospectives, but just doing retrospectives is not Scrum in my book. My experience with Kanban is still a little limited, but it seems to be an appropriate approach for these environments.
  4. Organizations where there is very little need to change. I’ve spent some time working with big profitable banks to adopt agile and without exception, they just can’t wrap their minds around the need for Scrum… because they are already so successful as a business. The general attitude is that Scrum is popular therefore we will call what we are doing “Scrum”, but it really isn’t. It’s Scrummerfall and Scrum-Butt wrapped up in the terminology of Scrum. They will adopt some Agile practices and get very modest benefits. I have seen minor improvements in team morale and minor improvements in quality and productivity, but certainly not anything near to what is possible for improvements. When we do assessments in this type of environment, we see Value Stream maps with waste at the 80-90% level so there is huge room for improvement… but it just doesn’t happen.

Scrum can definitely transform the world of product development. It can definitely act as a catalyst to get teams and organizations out of crisis. But that isn’t the whole world of work. I’m also concerned about the idea of using Scrum for general project management. There might be some good practices that are part of Scrum that would also be valuable in general project management (e.g. regular retrospectives, daily team meetings) but that doesn’t make Scrum a general project management framework.

I don’t claim that any of the above observations are “correct”. That’s partly why I am sharing – I would love to have a good discussion here about this because I think it is critical for us as Agilists to be able to answer this question well when we are asked: “what is Scrum good for?” – particularly since Scrum is by far the most popular Agile method.

I would love to hear other people’s observations about where Scrum works well (as I have defined “well” above) vs. where it either is only a modest improvement to existing approaches or where it might even not work at all.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM + Scrum(CSM) + OpenAgile + Kanban training in Markham Sept. 7 & 8

We have an upcoming three-day agile training seminar in Markham September 7 & 8, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM+Scrum(CSM)+OpenAgile+Kanban training in Toronto, August 22-24

We have an upcoming three-day agile training seminar in Toronto, August 22-24, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM+Scrum(CSM)+OpenAgile+Kanban training in London, Sept. 7-9

This 3-day training covers 3 Agile methods: ScrumMaster (the most popular Agile method), OpenAgile (the most widely applicable Agile method), and Kanban (a method that can be used together with other Agile methods).

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The BIG Difference Between Agile Teams and Project Teams

Last week I ran an Agile Coach Training session in-house for a large Canadian organization. It was just myself and five other participants. We were discussing possible things to do if there is a person on an agile team who is not able to work effectively in that sort of environment. One “intervention” we discussed was to “Assign Work”…

Pause

Now hopefully everyone who just read that phrase “Assign Work” had all sorts of alarm bells go off in their head!!!!

As an Agile coach, I would only do this under extreme circumstances. And I would always be fully aware of the consequence of assigning work. I would be removing that person from the team by Assigning Work. A person is not in an Agile (self-organizing) team if they need to be assigned work.

Guess what?!? THAT is the BIG difference between Agile Teams and Project (or Functional) Teams.

On a project, the Project Manager gets someone onto the team by assigning them work!!!!

On an Agile Team, a person is removed from the team by assigning them work.

Have you seen this happen? How did the assignee feel?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Report average velocity and fail 50% of the time

The question of “expected velocity” and long-term planning has come up at more than one client. A recent client conversation got me thinking, however, questioning how to interpret velocity when estimating and plotting a roadmap based on a current backlog of features. Assume, for a moment, a backlog of story-pointed features, and 10 good iterations (consistent team, no odd occurrences that would affect velocity). Mathematically average velocity (well, a mean really) is a 50/50 proposition for any subsequent iteration. Some organizations don’t find this level of confidence acceptable. What velocity should be reported as expected for iteration/sprint planning and roadmap forecasting, and how should it be used?

Context

Interpreting velocity, before anything else, requires some context. An agile organization that sees estimates as hypothetical might find this article is of less use. In fact, a good question is whether estimation is even a value-added activity. For this post assume an organization that sees strong value in estimation and planning.

Culture

The biggest piece of context is to know the organizational culture. This is important in two respects, and both of these cultural factors are important because they impact how Velocity is understood within the organization.

What is Failure?

First is the meaning of failure in the organization. Is failure to deliver what was committed to by the planned date considered a failure of the team, or is it simply a fact to be understood and accounted for in future planning? Even in Agile organizations, the former is often true and a hard habit to break. If not delivering to expectations is considered failure and has negative consequences, then that means that estimation is being treated not as estimation, but as prediction and contract. Velocity is therefore a commitment, and should therefore be used conservatively.

Consistency or Speed?

The second item to know is whether consistency and predictability of delivery is of a higher strategic value than the actual rate of delivery. This is often un-stated. Usually people want fast and consistent delivery. The truth is that you can get consistent, or fast software development, or a balance between the two. Lack of trust is usually a strong motivation to encourage consistency over speed, or a history of quality problems, etc. In this case, as well, Velocity is more of a boundary than an indicator.

Emotional Loading in Estimation (or why not Low-ball?)

If estimation is seen as binding, contractual, or limiting, then additional emotions get overloaded. Trust, promise, and betrayal are words used in such organizational cultures. Distrust is usually a strong factor, especially between silos (business vs. technology, company vs. project management vs. customer, etc.). So when people are asked to give estimates, even using agile-friendly mechanisms such as story points, there is usually a process of cementing that estimate into a part of an accountability model, so estimates start to get conservative. People are then accused of low-balling, others are accused of irrational expectations… we’ve all seen this. The language clearly becomes one of contention and blame. Even the term low-balling is often an outright pejorative term for estimating too conservatively.

This doesn’t happen only in agile environments, and project managers in traditional PMBOK frameworks have long factored risk into “contingency budgets”. Interestingly, however, if a Project Manager were to factor risk into the task estimates, they’d be “low-balling capacity,” yet if they were to factor it out and layer it on top of the project work, it’s “contingency budgeting” (At least in a few experiences I’ve had). Either way, someone’s adding a factor for uncertainty, based on the need to predict conservatively or liberally or somewhere in between.

That’s the point of the article: how can Agile projects use velocity to estimate as conservatively (or liberally) as is appropriate?

An average is a 50% chance to succeed (or fail)

Velocity is not a constant. It’s a set of instantaneous values on a curve, with instances being iterations. That means that it varies, and is therefore only meaningful statistically. So how do you reasonably use velocity statistically, and improve confidence? One way is to stop delivering against “average” velocity.

A lot of coaches use average velocity over the previous N iterations. This is not helpful for all sorts of reasons, if estimation is a commitment. By definition, average (well, actually a mean, but they’re close) is a 50/50 proposition. If you report the average team velocity (assuming it’s accurate), then about half the time the team will be under and about half the time the team will be over, statistically. So basically an average is a crap shoot, when taken in any given instance. It’s can only be good in the long run. For this to work, the long-haul has to include permission to fail and a lot of trust. Teams need to be able to go miss dates but will sometimes exceed dates and it should all wash out in the end. In organizations such as I’m describing, that trust isn’t there, so. Additionally, if the language of commitment is around meeting instantaneous iteration commitments (as opposed to delivering high-quality customer value as quickly as is sustain-ably possible) then you aren’t playing the long-game, you’re playing a very short-game.

Simulate Velocity, not work

In a PMI training course I took when I was at Sun Microsystems, we were nicely informed that two point estimates of tasks are a perfect way to fail half the time, per the above logic. One point estimates are just idiotic. Three point estimates were better. We simulated with a monte-carlo algorithm and found a curve and a distribution, and then determined a confidence level yadda yadda. Well, we’re trying to avoid wasting a lot of time estimating up-front, but one way to start representing velocity properly is to do the same kind of statistical modelling done in traditional product management, only simulate velocity, not work items.

In this approach, you take the last N iterations (say 10). Determine the maximum velocity (optimistic) and the minimum velocity (pessimistic), and then the mode (the velocity value that seems to occur most frequently). Then you do monte-carlo simulation so you get a statistical pattern. Now, you actually can determine an answer based on confidence. If you want to be right with an 80% confidence, you pick a velocity where 80% of the simulated runs were successful. (Note – there are a paucity of excel templates to do this math automatically, and often they are for sale. It would be nice to have a few functions with arbitrary distributions based on min-max-mode to help this along.)

It’s not perfect, and it’s a potentially huge amount of administrative overhead. Elsewhere I’ve referenced blogs that entirely oppose any estimation at all, but if you are gong to, then working statistically with simulation is the only way to take small sample numbers meaningful.

Commitment Velocity: Low-Ball as a policy.

Another approach, one perhaps controversial, but taught by some Scrum trainers is to pick the lowest historical delivered velocity. This is a commitment-based approach, on the assumption that building trust around consistent delivery is critical to building sound relationships where product owners and teams can safely state their needs and get things done with a minimum of contractual behaviour. By taking the minimum, you force a low-ball capacity, which means you can have high-confidence of success after a few iterations. You have, likely, after a while, some spare time on your hands. Teams can then choose to pull more work in (without adjusting their commitment velocity), work on “technical debt”, improve their skills, etc. A team could raise their commitment velocity in certain inflection points in the project. A new team member is added that provides a necessary skill not previously available, and after a few iterations the team is consistently hitting a higher number, but this is a careful process to ensure that they are committing, and if they don’t make their new number, it goes down to what they got accomplished.

Indemnify teams’ learning

An arguably healthier option, if you have built enough trust, is to simply indemnify a team from failing to meet the estimate. Since you’re doing mathematics on actuals to generate an expected future number, everyone can acknowledge that past behaviour is no guarantee of future behaviour, and simply use it for capacity planning. In this case, estimation is actually estimation, not commitment or contract. The team is expected to be ahead sometimes, and behind sometimes. The upside of this is that a lot of extra time isn’t spent playing with fictional numbers. Teams are spending their efforts on delivery as quickly-yet-sustain-ably as they can, and the organization treats them as trusted professionals in this. The temptation to assume you can predict the future is seen as folly, and the estimates are used to guide overall direction, not to make outward customer commitments.

Don’t be mindless

There may be other approaches, I’m sure. The agile community is certainly not short of people who love this topic and can talk for hours on “proper” estimation. The point of this post is merely to point out some options, and ask you to look at your organizational culture, team culture, customer culture, the meaning of terms like commitment, failure, success, consistency, speed, etc. As you understand the culture, balance consistency vs. speed, trust, and other factors to choose a method of estimation that meets your goals. Don’t do estimation based on your own, internal cultural assumptions, as you may have developed or been taught techniques that are useful when and where they were taught, but may no longer be so. Or maybe they weren’t so useful then either. Regardless, this because estimation cuts at the heart of the dialogue between producer and consumer, and establishes parameters for that discussion, it’s critical that you think your choice through.

[Christian also blogs at http://www.geekinasuit.com/]


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Book Commentary

AGILE Project Management with Scrum -A book by Ken Schwaber

Prior to the Certified ScrumMaster seminar I attended in August 2008, I read the book by Ken Schwaber called Agile Project Management with Scrum based on a recommendation from Mishkin Berteig.    After attending the seminar and becoming certified as a ScrumMaster I re-read the book.   The second reading was much more valuable than the first for I had a much better understanding of Scrum.   Here are my comments on this book.

What have I learned?

1.    The adoption of Scrum methodology is more about changing roles and behaviours than it is about embracing a new process.

It was obvious to me and to Ken that one of the greatest challenges facing those individuals when moving from a their current environment to a scrum environment was that they would need to change their behaviours.    In the former environment the team member would be directed and inspected based on what their project manager told them to do.  The PM is the boss and the team members are somewhat powerless.  In Scrum the team members take responsibility for their commitments and communicate their accomplishments on a daily basis.  The hardest change occurs when the project manager is asked to become a ScrumMaster.  The project Manager is familiar with assigning tasks and personally inspecting results. In the scrum environment they are the servants of the team, removing obstacles and facilitating the process.   As Ken states in this book some project managers have great difficulty transitioning into the ScrumMaster role.  They are unwilling to give up the power and position as a project master.   It is hard to move from the leader of the pack to become the sheep dog herding the sheep!

2.    Scrum is unforgiving for if you do not apply the fundamental principles it is likely your efforts to adopt Scrum will fail.

As I reviewed the numerous case studies Ken chronicled is was apparent that when organizations, Team members, Product Owners and ScrumMasters followed the terms, conditions and guidelines of the Scrum methodology, they tended to deliver on their commitments.   When they misunderstood, misused or deleted some portion of the methodology they tended not to accomplish their objectives.   The methodology is well thought out and works in many situations when used appropriately.

3.    Scrum enhances individual and team expertise.

I agree and totally support Ken’s opinion about the value of Scrum.   I have no doubt the individual team member is empowered and has a greater sense of achievement.    Obviously based on his case studies, Ken builds a strong case that Scrum allows the team to deliver quicker.  The process is more change adaptive, responsive to customer needs, timely and economical than traditional methods.   Greater energy and capacity is released in the team and individual team members.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Estimation and Pairing

I just read a recent article on PMHut called “Schedule Questions: Pair Programming and the PNR Curve“. There is much in this article that is important for agile project management… and much that should be avoided at all costs!

Estimating Projects

The bulk of the article is an explanation of the PNR curve (Putnam Norden Rayleigh curve). The explanation is sufficient and can be checked against other web articles about software estimation. The basic idea of the PNR curve is to find an ideal number of people with which to staff a project based on an estimate of overall project size (e.g. 72 man-months).

Take a moment to go read Fantasy Estimation (the comments here provide good additional material).

It should be clear now that any initial sizing estimate based on units such as man-months is ridiculous. So what is our alternative? What about an agile approach to estimation and planning?

Agile Estimation

Well, at a minimum, in an agile approach to estimation, we need to resolve some of the problems identified in “Fantasy Estimation”. So, we:

  1. Get the whole team that will be doing the work to do the estimation
  2. We weight estimates based on team maturity, knowledge of tools, knowledge of the business domain and the physical proximity of team members to each other
  3. We adjust our estimates of work remaining based on our results for work completed

The great thing about an agile approach is that it allows all these things to be done and to be done well. Scrum has a specific set of “Drag Factors” that can be used to weight the team’s estimates. And using a team’s past estimates vs. “actuals” is possible on an iteration by iteration basis… and this is possible because every iteration the team is doing the “same thing”: delivering an increment of valuable results (working software, edited video, organizational change, whatever is contributing to the project goals).

The other thing that agile methods allow is to make a distinction between estimation for planning and estimation for commitment.

So. It’s cool to learn about the PNR Staffing curve and the thinking behind it. It’s a little scary to see it being applied in an agile context when we have tools that are much better.

Pairing and Estimation

At the end of the PMHut article, the author, Mike asks a question:

What about pair programming? When using pairs on a team we could either:

  1. Continue as is, use the model to determine optimal team size and then encourage pairing to increase efficiency.
  2. Treat a pair as one hyper-effective person, so count pairs not individuals and increase team sizes accordingly.

This second option seems counter intuitive to agile, we strive for small teams to reduce communication channels, so I’m not convinced by this idea. I would be very interested to hear people’s thoughts on agile staffing curves. So, lots more questions than answers in this post, please let me know if you have any research or thoughts on the matter.

I wrote in response:

Mike, I feel like the options you present in your question at the end actually miss the true point of pairing which has to do with communication. I have never seen pairing done in such a way that two people always work together as a pair. Rather, pairing is promiscuous: people switch pairs frequently throughout a day, iteration or project. This switching has two communication effects: 1) the human interaction and gradual diffusion of information as people switch pairs 2) helping everyone understand all parts of the work as a result of frequently working on many different things. From an estimation standpoint, I expect that neither of your two options is quite right. Rather, the third option is to continue as is with existing estimation and then encourage pairing to increase communication. Increased communication shows up in a number of different ways, not just efficiency: risk mitigation, accelerated individual and team learning etc.

I would like to expand on this just a little. To me, pair programming or pair work of any kind has always been able to provide a number of benefits to projects. Problem avoidance is one benefit (lower defect rates, better code quality through constant inspection, spotting each other). Better communication is another benefit. Increasing the Truck Factor is yet another benefit.

None of these benefits have any direct bearing on estimating a project at the start, particularly since most projects sacrifice quality for schedule. From an agile perspective, since planning estimation is not commitment, it actually doesn’t even really matter! Get a conservative estimate for you project using whatever method you like, then start working and get a commitment velocity and see what the team can really do.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Plan Methods Oppose Agile Work Axioms

Plan driven methodologies which attempt to mechanize the process of doing work are in opposition to the three Agile Work Principles.

We are Creators
A plan methodology attempts to define intermediate and end work products independently of the input and effort of those who perform the work of creating the work products. This disenfranchises people from their work and leads to low morale. It also establishes a heirarchy of value for the people working on an effort where those who create the plans are perceived as more important or valuable than those who execute on the plans.

Change is Natural
This principle is usually acknowledged, but is usually described as a “problem” to be dealt with rather than as a basic principle to be fully embraced. A plan methodology has “change control” or “change management” and “risk management” and puts the whole notion of change in a negative light. This approach also disenfranchises people because they are constantly placed in opposition to reality.

Reality is Perceived
Plans attempt to legislate reality. “Thus and so must the project go” results in a constant struggle between the plan and peoples’ perception of reality. Plans marginalize the importance of perception on the belief that reality can be objectively understood. If reality can be objectively understood, then it can be mechanistically manipulated. Thus results can be pre-determined without regard for the perception of those results.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Certified ScrumMaster® (CSM)
Toronto
C$1595.00
Feb 25
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1795.00
Feb 27
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Feb 29
2020
Details
How to get AWS® Certification with BERTEIG [WEBINAR]
Online
C$0.00
Mar 3
2020
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1195.00
Mar 4
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1599.00
Mar 6
2020
Details
Agile Coaching at [YOUR COMPANY NAME HERE]
GTA
C$2000.00
Mar 6
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1599.00
Mar 7
2020
Details
Kanban System Design® (KMP I)
Vancouver
C$1795.00
Mar 9
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1495.00
Mar 9
2020
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1395.00
Mar 10
2020
Details
BERTEIG Real Agility Series: Essential Agile Metrics for Business
Online
C$0.00
Mar 12
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1599.00
Mar 20
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1599.00
Mar 21
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Mar 24
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Mar 26
2020
Details
Certified ScrumMaster® (CSM)
London
C$1525.75
Mar 30
2020
Details
Kanban System Design® (KMP I)
Toronto
C$1525.75
Mar 31
2020
Details
Kanban Management Professional® (KMP II)
Toronto
C$1525.75
Apr 2
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Apr 7
2020
Details
Licensed Scrum Master Product Owner® (LSMPO)
Toronto
C$1695.75
Apr 14
2020
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1015.75
Apr 14
2020
Details
BERTEIG Real Agility Series: The Cloud - Supercharge Your Agillty
Online
C$0.00
Apr 20
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Apr 21
2020
Details
Agile Coaching at [YOUR COMPANY NAME HERE]
GTA
C$2500.00
Apr 22
2020
Details
AWS® Certified Solutions Architect – Associate Level [Live or Virtual]
Toronto
C$1865.75
Apr 22
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Apr 23
2020
Details
Professional Scrum Master® (PSM I) [PSF Courseware]
Toronto
C$1270.75
Apr 27
2020
Details
Coach Skills for the Agile Workplace® (IPC-ACC)
Toronto
C$2020.00
Apr 27
2020
Details
Facilitation Skills for the Agile Workplace® (ICP-ATF)
Toronto
C$1500.00
Apr 30
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
May 19
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
May 21
2020
Details
Agile Coaching at [YOUR COMPANY NAME HERE]
GTA
C$2500.00
May 21
2020
Details
Introduction to Agile Ways of Working
Toronto
C$424.15
May 21
2020
Details
BERTEIG Real Agility Series: Expose Dependencies and Create Opportunity to Deliver Faster!
Online
C$0.00
May 22
2020
Details
Kanban System Design® (KMP I)
Toronto
C$1525.75
May 26
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
May 26
2020
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1015.75
May 29
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Jun 2
2020
Details
Coach Skills for the Agile Workplace® (IPC-ACC)
Waterloo
C$2020.00
Jun 15
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Jun 16
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Jun 16
2020
Details
Transforming Organizations with Agile Leadership
Toronto
C$424.15
Jun 18
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Jun 18
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Jul 28
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Aug 25
2020
Details
Coach Skills for the Agile Workplace® (IPC-ACC)
Toronto
C$2020.00
Sep 2
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Sep 29
2020
Details
Coach Skills for the Agile Workplace® (IPC-ACC)
Toronto
C$2018.00
Nov 2
2020
Details