Archita's Blog: Agile-FAQs

This is a post on all the FAQs on agile development needed for an interview compiled together.

What is Agile?
Agile methodology is an approach to project management, typically used in software development.
It helps teams respond to the unpredictability of building software through incremental, iterative work cadences,
known as sprints. This methodology that inspired it: waterfall, or traditional sequential development.

Why Agile?
Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. Agilemethodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

Agile methods focus on shorter iterations, in which the software is brought to a releasable level of quality fairly often, usually somewhere between weekly and monthly. Short iterations provide numerous technical and management benefits. On the technical side, the main benefit is reduced integration risk because the amount of software being integrated is kept small. Short iterations also help to keep quality under control by driving to a releasable state frequently, which prevents a project from accumulating a large backlog of defect correction work. On the management side, the frequent iterations provide frequent evidence of progress, which tends to lead to good status visibility, good customer relations, and good team morale.

Agile methods also usually treat requirements as more dynamic than traditional methods do. For some environments that's a plus and for some it's a minus. If you're working in an environment that doesn't need a lot of long range predictability in its feature set, treating requirements dynamically can save a lot of detailed requirements specification work and avoid the "requirements spoilage" that often goes along with working through a lengthy backlog of detailed requirements.

What is Agile software development ?
Adaptable software creation, also known as agile software development. Agiledevelopment is a style of software development that emphasizes customer satisfaction through continuous delivery of functional software. Based on a variety of iterative development disciplines including extreme programming (XP),agile methods put developers to work in small teams to tight budgets and short timescales. In contrast to traditional software development methods, agiledevelopers liaise continuously with business clients, aiming to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirement in response to evolving business needs

What are the Advantages of Agile Methodology?

Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Face-to-face conversation is the best form of communication
Close, daily cooperation between business people and developers
Working software is the principal measure of progress
Continuous attention to technical excellence and good design
Simplicity
Regular adaptation to changing circumstances
Self-organizing teams
Projects are built around motivated individuals, who should be trusted
Even late changes in requirements are welcomed (this does not mean code & run.
Instead removing an existing feature or moving a deadline forward to accommodate late/unplanned feature requests

What are Agile Methods?

Agile Modeling
Scrum
Agile Unified Process (AUP)
Agile Data Method
Essential Unified Process (EssUP)
Extreme programming (XP)
Feature Driven Development (FDD)
Getting Real
Open Unified Process (OpenUP)
Lean software development

What are Agile practices?

Test Driven Development (TDD)
Behavior Driven Development (BDD)
Continuous Integration
Pair Programming
Planning poker

What is Agile Testing?
Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm.

What is Application Binary Interface (ABI)?
A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.

What are the different approaches to testing on agile development projects?
1. You want to test as early as you possibly can because the potential impact of a defect rises exponentially over time In fact, many agile developers prefer a test-first approach.
2. You want to test as often as possible, and more importantly, as effectively as possible, to increase the chance that you will find defects. Although this increases your costs in the short term, studies have shown that greater investment in testing reduces the total cost of ownership of a system due to improved quality.
3. You want to do just enough testing for your situation: Commercial banking software requires a greater investment in testing than membership administration software .
4. Pair testing, just like pair programming and modeling with others, is an exceptionally good idea.

What is the biggest challenge when implementing Agile methods? The biggest challenge we see in our consulting and training business is walking the walk. You can't just say you're doing Agile. You have to follow through with specific actions. Of course that's the same problem we saw years ago with object oriented methods, and before that with structured methods, so that problem isn't unique to Agile.

The most common specific challenges we see are simply the challenges of "turning the battleship" in a large organization to overcome the inertia of entrenched work practices and expectations and getting reoriented to do things in a different way. You have to muster the resolve to actually work in short iterations. You have to build frequently, at least every day, and you have to develop the discipline to keep the build healthy. You have to push each iteration to a releasable level of quality even if that's hard to do at first. As before, this problem isn't unique to Agile. If we're working with an organization and find that their biggest need is to do a better job of defining requirements up front (which isn't very agile), "turning the battleship" to define better requirements up front will be just as hard.

In what environments will Agile be most successful? Full-blown Agile seems to me to be best suited for environments in which the budget is fixed on an annual basis, team sizes are fixed on an annual basis (because of the budget), and the project staff's mission is to deliver the most valuable business functionality that they can deliver in a year's time with a fixed team size. This mostly describes in-house, business systems dev organizations.
Full-blown agile (especially the flexible requirements part) is less-well suited to companies that sell software, because maintaining a lot of requirements flexibility runs counter to the goal of providing mid-term and long-term predictability. We've found that many organizations value predictability more than they value requirements flexibility. That is, they value the ability to make commitments to key customers or to the marketplace more than they value the ability to "respond to change."
For anything less than full-blown Agile, however, we find that many agile practices are well-suited to the vast majority of environments. Short development iterations are nearly always valuable, regardless of whether you define 5% of your requirements up front or 95% up front. Keeping the software close to a releasable level of quality at all times is virtually always valuable. Scrum as a management style and discipline seems to be very broadly applicable. Small, empowered teams are nearly always useful. I go into more detail on the detailed strengths and weaknesses of specific agile development practices in my executive presentation on The Legacy of Agile Development.

What is the future of Agile? Agile has largely become a synonym for "modern software practices that work," so I think the future of Agile with a capital "A" is the same as the past of Object Oriented or Structured. We rarely talk about Object Oriented programming anymore; it's just programming. Similarly, I think Agile has worked its way into the mainstream such that within the next few years we won't talk about Agile much anymore; we'll just talk about programming, and it will be assumed that everyone means Agile whenever that's appropriate.

What is Agile? What would be your 30 second Agile elevator pitch?
What is the difference between Agile and Scrum? / What are some other Agile methods/frameworks?
What is missing from Scrum? What other developmental practices would you suggest helps with providing deployment value to a software development team?
Why is the daily standup/Scrum valuable for the team? – How do you make an ineffective standup more effective?
Your team is ready to plan (sprint plan) for work on Wednesday, but the requirements (stories) aren’t ready yet. – What type of planning would you do? / How would you lead your team to be ready to start developing on Wednesday?
What is a Scrum of Scrums? Why is it valuable?
Name 3 key characteristics of a good ScrumMaster.
Name 3 roles a ScrumMaster plays in a development team.
Name 2 techniques for prioritizing user stories (MoSCoW, Noriaki Kano’s Objective vs Subjective Weighting, Numerical Prioritization Strategy, Relative Weighting, Theme Screening, Karl Wieger’s Benefit Scale)
Name 1 technique for User Story creation (Bill Wake’s INVEST, Ron Jeffries 3 C’s)
What is the MoSCoW prioritization technique?
What is the reason we use User Story Personas?
What is Noriaki Kano’s prioritization technique? (Obj + Subj = M, One dimensional, delighters)
What is relative weighting for user story prioritization? (1-9 relative benefit)
What is theme screening for user story prioritization? (Baselining a story)
What is Karl Wieger’s Benefit Scale prioritization technique? (Essential, Conditional, Optional, 1-9 Relative Benefit, Relative Penalty, Total Value)
What is Ron Jeffries 3 C’s? – Card, Conversation, Confirmation
What is Bill Wake’s INVEST? – Independent, Negotiable, Valuable, Estimate-able, Small, Testable)
In Agile, why do we estimate size, not duration in the beginning? What does this look like?
How do you continually grow your craft as an individual and employee?
What do you read? What are you reading right now?
In an Agile organization, explain to me what you do without using the words “Scrum,” “Agile,” “Iteration” or any other Agile buzzwords. How does what you do add value to an organization?
Organizational transformation leveraging Agile – What role did you play?
How was the organization setup to support development efforts to use Agile?
What challenges did you face while working with an Agile methodology? How did you overcome those challenges?
What has been your biggest mistake as a ScrumMaster or Agile project Manager in your current position? How would you think back and fix it?
Where did you help a team’s process mature using Scrum? Do you believe this is part of the job of a ScrumMaster? Why?
How would you scale product ownership to an enterprise beyond just product ownership for a team?
What other development techniques have you used with your Agile teams? What made them effective?
Can agile methodology be applied also in other than software testing and development projects?
While asking these sort of agile testing interview questions, employers try to recognize if you really understand the benefits of this methodology and can see a practical application of it in various areas of business. To state that this methodology can be, and maybe even should be, applied in all the instances and test cases where we have insufficient entry data, or work in an unknown area, or simply work within a small team, or where many unpredictable variables take place is a good answer. It is in fact used quite commonly in bio-medicine, biochemistry or physics. Anyway, it could be used in many other areas. Just let your imagination to work and you’ll answer these sort of agile methodology interview questions easily…

Are you able to name five main characteristics of agile methodology from your point of view?
Every person can approach agile methodology from different angle. The employer tries to find what your angle is, and if it is the one they are looking for, while asking you these sort of agile methodology interview questions.
So in fact, the right answer really depends on your point of view. However, if you look for characteristics that are usually “positive” for the company, you should go with things like cross-functional team composition, face-to face communication, solving problems immediately after these are identified, working solution as a primary metric of progress. If you do not like our suggestions, you will have to figure out something by your self.

Describe a case where you personally used the agile methodology (or was a part of a team which used it).
This question is very important. One experience is better than whole book of theory, that is truth. Before the interview think carefully where you have used the agile methodology before. If you can not find any example in your professional life, look into the personal one. Even here are some fields where agile methodology can be very handy. Think about it in advance, prepare what you will talk about and focus on the positive results associated with the implementation of this methodology in your project. Doing it like this, you will be well prepared for all these practical agile methodology interview questions. We wish you good luck!

Explain to me what you do without using the words "Scrum", "Agile", "Iteration" or any other agile buzzwords. How does what you do add value to the organization?
The reason I think this is important is that the whole organization may not have drank the agile Kool-Aid and it's important for the Scrum Master to liaise with the customer(s) and other areas of the business to remove impediments and keep the team productive. In order to do that the Scrum Master must be able to communicate with non-"agile" team members in their language. If they can't do this, they are probably going to cause as many road-blocks as they remove.

What do you see as your biggest mistake being a scrum master in your current position? How would you think back and fix it?
We're moving back to a waterfall process, you're position has been closed....(this is where they should try and convince you what you are doing is a mistake, they might need a little prompting to get them started to make the argument as to why to keep moving with agile.)
1. Have you ever had a role similar to this in previous positions? What was the hardest obstacle you had to remove in such a role?
2. What do you consider to be the top qualities that a Scrum Master should possess and why?
3. Have you had to convince people of the benefits of using Scrum? What were the keys to success in that? If you haven't had to do that, how do you think you would approach it?
4. Where did you help the team's process mature in using Scrum? Do you believe this is part of the job of a Scrum Master? Why do you believe that?
These are just general questions to see what kind of past experience and knowledge is there that would likely be part of where I'm more curious in terms of tone and other factors in giving an answer than the words of the answer itself. There may be follow-up questions depending on the answer as there could be something that opens up that I'd follow-up in an attempt to "Finish him" as Mortal Kombat would dictate if the situation presents itself. ;)

Number 1 with a bullet:

List the last 3 projects you worked on and what your contribution was.

Ask for references and everything else is PR.

“How would you effectively prioritise your product backlog in order to meet a defined release date x sprints in the future?”

Example of how I resolved a conflict between customer demands and internal resources”

Do you work on agile ? Describe the process you follow.

“How does a technical team handle agile business requirements?”

“In Agile development methodology,explain the difference between the pig and the chicken.”

Distinguish between (Agile) and (Scrum, XP and other methods)
Explain the importance of inspect and adapt for software development
Tell the story of how agile came about and how it started.
Relate to Agile as a mindset; a set of values and principles not just a process
Explain the four values of the Agile manifesto and the 12 principles.
Explain the Declaration of Interdependence
Describe how Agile teams are structured and understand the categories of project stakeholders (PO, Sponsors, Users, Team)
Understand that the plan should be for delivering software/technology (not only documents) at the end of each iteration.
Understand how to establish a project charter that gives the overall picture of the product, the project and the business value.
Express the importance of having a project charter
Demonstrate the ability to model requirements in a lightweight manner (Stories, Use Cases)
Explain how and why requirements are managed and planned throughout the project not just upfront.
Explain how to work with requirements in two levels – overall and detailed.
Explain the concept of a Timebox and why it is important (always deliver on time, Incremental delivery – and feedback)
Understand what is “velocity” and its importance
Demonstrate how to calculate team velocity
Explain how retrospectives are conducted
Discuss the importance of retrospectives
Practice being part of a retrospective
Explain the idea of a daily standup meeting and its importance
Describe an ideal Agile Physical environment (walls, whiteboards, etc.) – noise protection from other groups – pros and cons – how to setup groups to work
Explain the importance of information radiators
Understand the difference between unit tests and acceptance tests
Demonstrate at least one estimation technique (use case points, wide band Delphi, yesterdays whether)
Explain how to answer the question of “when will we finish this project”

What is the difference between a release, and an iteration?

The “right” answer is “A release consists of many iterations”.

I answered “They are mutually exclusive”.

For one thing, the “many” in the “right answer” is misplaced. I’ve done projects where we released every iteration. That’s not “many” iterations.

Secondly, sometimes an agile team works on multiple tracks across multiple products within iterations that can be released independent of iterations and of other products. What if your team also does production support? Right – this isn’t the clean, book-learning of “a release is comprised of a number of iterations”. It’s based on the reality of teams out in the wild. If you want to test, I think it should be based on reality rather than some simplified Pollyanna view where teams work on only one product at a time and discover that their work magically fits into n-iterations. (Note to APLM tool creators).

Hence my answer: they are mutually exclusive.

What is the timing of when XP teams work on features?

The “right” answer: “Sequentially”. My answer: “In any order”.

Clearly “once all the requirements are complete” is not correct.

And “simultaneously”, another possible answer, is … well… I don’t know. I guess it could have been a reasonable response.

“Sequentially” doesn’t make sense to me, though I see how they inferred this as the correct answer. I think it’s about proceeding “sequentially” through the prioritized backlog (or – since we’re talking XP here, probably Master Story List is more apt). A couple of problems with this though:

If I have multiple dev pairs they are almost always working on different storiessimultaneously.

The sequencing of the backlog (using biz value, risk, etc.) is an exercise that causes stories to flow into an iteration. Within an iteration – typically the focus of the XP Team as stated in the question, the sequence is usually not so important (unless you have dependencies or other factors driving sequence).

Of course, Kanban throws a whole ‘nother wrinkle here. Still – multiple people are working on different stories simultaneously.

What is the definition of method tailoring?

Never heard that term before, but I guessed right. More context on the question, or a rewording, would be appropriate.

On an agile project, sponsors, developers, and users should be able to maintain a constant pace for what time period?

The “right” answer is “Indefinitely”.

We talk of “sustainable”, not “constant” pace. “Consistent” may be more palatable, but still – “constant” seems wrong.

Secondly – the pace question is usually a comment on the agile team – not the external stakeholders, and certainly not the users.

I answered “for an iteration”. I have always thought of the iteration beginning and ending ceremonies – particularly the retrospective – as a break from the pace of the iteration: a time to come up for air, collect our thoughts, then hunker down and proceed. Again – Kanban has a more constant pace, so adds another wrinkle.

With respect to a sprint, what does velocity measure?

The answer is “the amount of work a team can accomplish in a given sprint”.

First – velocity is a more general agile term that is not specific to scrum. I would generalize the question/answer.

Second – velocity is not necessarily what it “can” accomplish. There’s historical velocity, for instance, which measures what a team has accomplished in past iterations. I would modify the answer to say “accomplishes” rather than “can accomplish”.

Ah well. I’ve always found these attempts at agile assessments fraught with confusion. Multiple choice tests are difficult when the content is complex and context-dependent.

I’d love to hear feedback. Did you take the test? How’d you do? Any comments on my criticisms?

Stand-up efficiency and effectiveness

Posted on October 6, 2011 by Adrian

I attended a user group meeting last week where a participant asked the question: “How do I keep my stand-ups from going so long?”. He cited greater-than 30-minute time for 10 people.

I didn’t get a chance to talk to him, but here is my advice.

First, discuss the topic with the team. Ensure that there is agreement that long stand-ups are negatively impacting the team. It may be (but it’s unlikely) that the content of the long stand-ups is important to everyone,

Determine root cause. I find a couple of causes that can be addressed in different ways.

Long-winded people offering irrelevant input or input that is relevant to only one other person: Record the contributions of each of the long-winded folks and review with them. Identify specific content that is not relevant to the team.

You’ll often find paycheck rationalization offerings (e.g. “I had my one-on-one with my manager yesterday”).

Or you may find someone simply regurgitating their calendar (managers are likely to be the offenders here).

Or it could be politically driven public thrashings that are more appropriate to share in private (“David – you seem to be checking code in without any tests. Remember, we agreed that we would write tests”).

I’ve seen stand-ups where multiple team members will regurgitate events in which the whole team participated. If the whole team attended the iteration planning meeting, there is no need to mention this in the stand-up.

Start timing folks. If anyone talks more than 2 minutes, make them stand on one leg, or ask them to extend their arm holding a heavy book while talking. Or use a timer (obnoxious alarms are best).

Conversations that are not relevant to the whole team: Institute a “parking lot” flip chart or white board where topics for further conversation can be captured for discussion after stand-up. Ask the whole team to help identify potential parking lot items when they occur; add them to the parking lot when identified and move on. Ensure that those follow-on conversations occur (else you run the risk that folks will continue to insist on in-stand-up dialog).

Use a speaking token and ask the team to be rigid about not talking when they don’t have the token. As conversations occur, the token passing will make it obvious that a conversation is occurring, which should help folks to self-identify opportunities to use the parking lot.

Explain to the team that the stand-up is not the only opportunity for conversation during the day.

Use a laser pointer to have folks point out the relevant stories/tasks on the physical card wall as they speak. They will be less likely to pontificate on irrelevant details if they have no card to point to.

I’ve attended stand-ups of over 40 people that have taken less than 10 minutes. That’s less than 15 seconds per person. Granted, these were teams that were pairing, so oftentimes the contribution of the second of the pair was of the form “ditto Joe”. Still – if a team of 40+ can get it done in 10 minutes, there’s no reason why your “2-pizza team” cannot.

Posted in Agile | Leave a comment

Prioritizing vs. Sequencing the Product Backlog

Posted on June 30, 2011 by Adrian

A primary tenet of agile software development is doing the highest business-value work earlier. The idea is that you achieve a minimal marketable feature set as early as possible so that a) you can issue releases earlier and b) if the money runs out, you have something more valuable than if you didn’t sequence your work in that manner.

Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.

When most folks talk about the backlog order, they refer exclusively to business priority.

I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.

Factors to incorporate into sequencing decisions:

Business Priority
Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don’t want to fill your iteration bucket with only large stories, because you’re losing the opportunity to slip in smaller stories. For example – if a developer finishes a story at 3pm on a Friday afternoon, you’d probably rather have him knock off a small story in the next couple of hours rather than start a large story.
Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example – if you have performance or scalability requirements that are risky, it’s better to implement the stories that are sensitive to those requirements earlier.
User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they’ll feel that their input has been ignored.
Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the “happy path” of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.

As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don’t forget to consider these other factors as well.

Posted in Agile, Product Management, Project Management | Leave a comment

Feedback Manifesto

Posted on June 29, 2011 by Adrian

I have come to value

Verbal, constructive feedback over written evaluations
Measuring output over measuring input
Frank feedback from colleagues over speculative management judgment
Real-time, frequent feedback over periodic high-ceremony assessments

Though the things on the right are commonplace and often dictated by antiquated HR policies, I value the things on the left more. Much more.

Principles

Giving feedback

My highest priority in giving feedback is to help my colleagues improve – to benefit them individually and the organization collectively. I always preface my feedback with this sentiment.

I understand that not all recipients are comfortable with feedback. I choose the time and place of delivery to respect this sensitivity.

I always ask the recipient if he/she is willing and receptive to feedback at that time/place and graciously accept “not now” for an answer.

My feedback focuses on behavior and outcomes – not the person.

When providing critical feedback, I consider the constraints and challenges in play at the time of the performance for which I am providing feedback.

I acknowledge intelligent risk-taking as a necessary component of creativity and delivery of value and incorporate my appreciation for it in my feedback.

I ask for feedback on my delivery in order to continually improve my ability to give constructive, valuable feedback.

Receiving feedback

I welcome critical feedback about my performance as a gift, and express my appreciation accordingly, regardless of whether I agree.

If I am not in a good place to receive feedback, I respectfully request an opportunity to reschedule.

I refrain from defensiveness or questioning the motives of the person giving me feedback in order that I can absorb the essence of the feedback.

Posted in Agile, Feedback, HR | Leave a comment

The case against iteration based re-estimation

Posted on June 20, 2011 by Adrian

Many agile practitioners recommend re-estimating stories at the beginning of each iteration. I disagree with this practice.

For one thing, I believe it’s a waste of time. Any value that you might get (which I doubt – see below) from the practice is lost on the time spent.

It’s worse than that though. By re-estimating the iteration’s stories, you are almost always estimating with a greater level of detail than what you had originally. With this increased level of detail, in my experience, estimates tend to grow.

Why is this a big deal?

Let’s try an example.

I come in to my iteration planning meeting with 30 points worth of stories from the backlog. The team commits to those stories, but in re-estimating, the 30 points inflates to 40. In fact, this always seems to happen, as the team gets a little nervous about hitting their historical velocity and they know management is paying attention. Let’s assume the team gets them all done. This increases the observed velocity by a third (40 points is a third more than 30). Now, let’s say I have 120 more points left in the product backlog to get to the minimal marketable feature set for release. How many more iterations are left?

If you said 3 more iterations (i.e. 40 points per iteration gets you to 120), you are ignoring your team’s tendency to inflate estimates. Assuming your estimate inflation rate is consistent (a third), you really don’t have 120 points remaining, you have 160 points, or 4 more iterations remaining. Or, calculated another way, if you consider only the initial estimates to calculate your velocity (30), then you can determine that you have 4 iterations of 30 remaining. In both cases, you end up correctly predicting 4 more iterations. Then again – if you use the initial estimates, what value did your re-estimation from 30 to 40 provide you ? I say none.

If you regularly re-estimate at iteration planning meetings, make a note of the original vs. the updated estimates. See if they grow. Consider what impact this is having on the accuracy of your release planning.

OK, I can hear you now. “My team’s estimates don’t inflate … some go up; some go down”. I haven’t seen this, but let’s say you do. Let’s revisit the example from above with this assumption. You go into the iteration planning meeting with 30 points and walk out with 29. Your velocity is not materially impacted. You are still on track with 3 remaining iterations (roughly). So the question is this: what value did that re-estimation provide? I say none.

When *do* you re-estimate then?

I believe in updating estimates when information arises from experience that pertains to some shared aspect of a subset of stories. For example, let’s say that your retrospectives have shown that every time you have a story that hits a certain database, it ends up being much more effort than expected. In a case like this, it makes sense to revist those database stories to ensure that this knowledge is incorporated into those estimates. I call thisaspect-oriented re-estimation (adapted from the term “aspect-oriented programming”).

Posted in Agile, Project Management | 2 Comments

The case against Chickens and Pigs

Posted on June 18, 2011 by Adrian

Schwaber and Beedle’s Scrum book introduces the pig and chicken fable to illustrate a point. It goes something like this:

Chicken:
Let’s start a restaurant!

Pig:
What would we call it?

Chicken:
Ham n’ Eggs!

Pig: No thanks. I’d be committed, but you’d only be involved!

The story is used to illustrate a difference between
a) the core team members – the “pigs” who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors – the “chickens” who contribute but are presumably not “sacrificing” for the cause

First – I think the analogy is confusing. I always have a hard time explaining it and I haven’t heard a coherent verbal description of the concept. There’s got to be a better way to make the point.

My higher purpose here, however, is to extinguish the point.

A commonly cited rule is that “only pigs can talk in the stand-up”. There is an underlying premise here that anything a “chicken” or non-core team member has to say is wasteful of the team’s time. A corollary perhaps: anything a core team member has to say is important.

I have participated in stand-ups where chicken “contributions” have been extremely valuable. Example:

pig: “My computer monitor froze last night; I need to order a new one”
chicken: “Stop by my desk after stand-up. I have a spare”

pig: “Today, I’m meeting with the product owner to review stories for the next iteration”
chicken: “Product owner is out sick today. Let’s talk after stand-up about rescheduling or doing it remotely”

Or how ’bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is “pass” (meaning – there’s nothing of import to the team to share). But maybe she’s got something important to say:

chicken: “Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I’d like to sit down with Joe to review some of them and get stories added to the backlog”.

What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.

I’ve also witnessed many examples of core team members’ verbosity and sharing unimportant information.

pig: “Yesterday I had a one-on-one with my manager and worked on my mid-year performance review”

Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone’s paycheck for the time they spent in the office.

pig: “I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn’t figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website – thank goodness for Google translation – but it’s kind of funny how they botch the translation, I mean, it’s not exactly the King’s English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I’d be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.

OK, I made all that stuff up. This guy needs some coaching on being more succinct. There’s some valuable info in there (“hey everyone – make sure you have those two patches”, and “I should be done today”) but it’s buried in irrelevant detail.

My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense – about what’s valuable to share – should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.

References:

http://blogs.construx.com/blogs/stevemcc/archive/2007/10/08/5-questions-on-agile-development.aspx

http://www.jaganinfo.com/blog/post/Agile-Interview-Question-and-Answers.aspx

http://agilescout.com/essential-scrummaster-interview-questions/

http://interviewpenguin.com/agile-methodology-interview-questions/

http://programmers.stackexchange.com/questions/59167/scrummaster-interview-questions

http://ricoslist.com/?page_id=5847

http://www.coriandertech.com/