Scrum is the "only sane, rational way to manage dynamic processes"

So... let me start with the setup. It was asked in the Agile Alliance LinkedIn Group whether the agile community is mature enough to coherently discuss a "maturity model". I was one of the first two to respond that answered down similar lines-

Mature enough, yes. Coherent, no.

Agile is a philosophy and culture. It is an umbrella term for a set of best practices... Scrum & XP being only two. I believe that getting everyone to agree on an AMM will either destroy the continuing evolution of the movement or marginalize non-core movements that are adding to it (think of Kanban/Lean in the last year).

The discussion continued on an interesting path including CMMi and other maturity models, the pro's and con's and various gut reactions to what this would mean. All good stuff.

But in the middle of this, Melvyn Pullen and I got on a tangent that started with him proposing an agile maturity model that was focused solely on Scrum for the first few steps. I questioned this since agile has many flavors, and enforcing Scrum as the first step seems limiting.

The problem I have with a maturity model defined this way is that it implies to all newcomers that it is the ONLY way. The manifesto was signed by 17 people of 7 methodologies/practices. They didn't identify Scrum as step 1 down that journey.

He responded with,

I believe that Scrum is the only sane, rational way to manage dynamic processes.

and

It is my opinion that Scrum is the only management technique that comes from the agile camp that could be used to introduce other agile processes.

Comments?

My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

Individual Recognition on a Scrum team

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

What is Iteration Zero?

Someone asked a very interesting question in the Agile Alliance LinkedIn group. Discussions about iteration zero have come up before, but this one was specifically focused on the situation where the architecture was not well understood.

In case you are new to Agile or Scrum, iteration zero is the term for that first sprint where you know you won't be delivering software that is adding value for the customer. It's the "let's-get-our-ducks-in-a-row-so-we-don't-bomb-the-first-sprint" sprint.

Many people use sprint zero when they transition to agile for converting their project plan into a backlog and seting up the environments needed for CI and other XP practices. Some use it to kick off a project and understand the underlying system being built on top of.

In this discussion though, it got me to thinking about a past project where we were starting from scratch. We had nothing, and we had never developed in this technology before. So, what to do?

Remember, a sprint should always have an outcome or goal. And, it should always be demonstrable! The original poster asked about unknown architecture, common impediments, and differences to non-agile projects. Here's what I contributed to the forum:

Iteration 0 should result in a compiled installable "Hello World!" system (example: user shall be able to login and logout). Common impediments are purchase, license, hardware, network, and system related.

In an ad hoc PM practice (or traditional), there would be a huge "balloon payment" (to borrow from technical debt metaphors) at the end of the project to take this built system and install it in the real world. Iteration 0 is a way of beating this problem up front and then refactoring along the way as you learn instead of having to rebuild based on the mistakes uncovered at the end during "stabilization".

What do you think?

It's all about getting groceries...

When the average college student goes to college, they suddenly have to fend for food themselves. Most campuses provide some type of food source insuring students don't starve to death, but cafeteria food isn't always up to snuff for the tastes of the average 18 year old so they wander out and make their first true grocery run. How does this typically develop?

Phase One- Wander around and find stuff that seems like a good idea.
Result- Realize very quickly within a few days that you forgot stuff that you needed and what you got wasn't really a wise choice. That 3 tub pack of chocolate Kozy Shack pudding seemed like a good deal until you went home and ate it all within 24 hrs. Now you need to make another trip for food that will actually give you some energy for mid-terms.

Phase Two- Realize over time that you don't like wasting time grocery shopping; make a list of groceries and go get those items.
Result- This helps add efficiency, stay within a budget, insure completeness, and aids in blocking useless (or unhealthy) purchases.

Phase Three- You quickly get bored of canned food, cheese n' mac, and spaghetti; it's time to decide what you want to eat/cook in the coming week, then make the grocery list
Result- You shift from always having stuff in your kitchen, to having what you need to make the right meals from that stuff. By working backwards, you insure you are happy with the outcome.

So, what does this have to do with agile or project management?

Phase One - I can't tell you how many companies have a development team that just wanders around and does what seems will help run the business or quiet the screaming managers. Kind of like the hungry college student's stomach, this is simply an id response to filling the basic needs. Unfortunately like the cozy shack pudding example, this doesn't always turn out best for them either.

Phase Two - There comes a point of time where the team can't keep everyone happy. Work starts falling on the floor and some things don't get done. Organization is suddenly required. The team has to start making lists and prioritizing work. They have to consciously decide which things won't get completed to insure that the right things do get completed. They need to stay focused on the list and not everything else that draws their attention (backlog management anyone?)

Phase Three- To really mature as a team, you have to start focusing on your DONE criteria. What is being accomplished? What is the goal you are trying to reach? What is the business value being achieved? The work isn't DONE until you meet this!

Now, lets assume that college student is growing up... or maybe they are maturing their cooking to impress someone they are dating:

Phase Four- ask the people who ate the food what they liked and didn't like. Adjust selected meals accordingly and then adjust the grocery list.

For the agile team... this is the retrospective.

Bored in the standup? Raise your hand...

I just read this interesting post about a scrum team that borrowed the concepts of yellow and red cards from soccer to aid their standups. 3 yellow cards or 1 red card means "move on".

Unfortunately, I live in a country where soccer is not the biggest sport... and I'm sure we would just misplace the cards.

So, let me share what has been working for my team for over a year now...

If anyone in the group feels that the current topic is not relevant to the group, they slowly raise their hand. They do it slowly to not be obtrusive and rude. If other people agree with this person, they can decide to also raise their hand. If there seems to be visible consensus, the people speaking must quickly assess their conversation and decide how to close it. They can either put it on the parking lot, or realize they aren't getting anywhere with it and just stop.

The parking lot is a list on the wipeboard in the team room. The person closest to the board writes the topic and the names of the people who are involved. At the end of the meeting, those people stay behind to pick the conversation back up.

If the person raising their hand is alone when their hand is fully raised, they suddenly realize that they are alone in their stance and drop their hand. At this point they wait for the good of the team since clearly, everyone else finds the conversation valuable.

And yes... our standup is short. We have about 15-20 people every day... and we average about 17 minutes (15-20 minutes) even with these included conversations.

Recently, we had an amusing moment when someone raised their hand on themselves...

Burndown charts as an indicator...

Jack Milunsky posted an interesting point in the Agile Project Managers group on LinkedIn. I normally agree with him and like his work (actually, I still do here)...

His core point is quite valid. The point of the burndown shouldn't be to drive a team towards focusing on the team's ability to match a perfect trend line. This is something I totally agree with. I've seen teams with perfectly straight lines on their burndown and I've learned that this is a big flag! That being said, his following sentence:

I believe that the underlying goal should not necessarily be about staying below the estimated time line in a burndown chart (although this would be nice).

..might set the wrong tone for a newbie to agile. I wanted to address that here.

Joe Blotner captures this well with the following statement:

Scrum doesn't solve your problems, just make them visible, so you can solve them.

...which I'm sure that Jack would agree with.

But... I want to state that I think the main goal of a burndown IS to trend downwards. This isn't the same as staying below the estimated line, but I want to be clear... if the trend isn't down, then you are going backwards. As a business person (PO), I would not accept a burndown going up or flat too long. This is a sign that I'm spending money and there's no sign of progress (both in uncovering all the unknowns and in making progress). I'd almost prefer seeing the line spike up and then start working back down so I know the problem is behind us. A flatline always triggers me to ask "but when will it end?"

That being said, if this is what was happening before agile, then Joe is correct. Agile has helped you focus on this and now you can try and fix it.

Little nuances I know... but I wouldn't want to see a new scrum team looking at their burndown and saying... "eh, that's okay for now... let's figure it out in a few days (or at the end of the sprint)."

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Does a SM have to be technical?

Kyle Smith asked the following question in the Agile Coaching LinkedIn group:

Often job postings prioritize extertise in a specific technology over attributes defined by Agile. Can a CSM succeed w/o being a subject matter expert for a particular technology or industry?

Keith Sterling responded with:

I don't think you need to be a subject matter expert, but I personally believe you have to have some level of understanding of the technology involved, otherwise you will find facilitation extremely difficult.
As a scrum master people will be looking for you for guideance, when you are planning and cutting tasks its important that you atleast know what the team is talking about and why tasks and plans are being proposed in a specific way.

Scott Duncan made several good points including this one:

Sometimes, skill-specific requirements are there because the org's culture will not "respect" someone in a more "mgt" or consultative position without low-level tech'l skills regardless of the fact that the role will not require them to actually use those skills.

My points were the following:

It depends on the team. Without getting into a debate of which is academically better (though I have an opinion), I see two types of agile teams...

1- a team of developers
2- a blended team of roles including dev, analyst, test, usability, etc

In option 1, it is important. You need to speak the language of the team since the team is speaking tech and you need to be the translator to the business.

In option 2, it is not. The team is a holistic group, let the tech folks speak towards business goals and value. Everyone should be focused on what is being delivered in business terms. The non-tech folks need to understand tech and vice versa. In this scenario, the CSM needs to be in between the knowledge of the tech and non-tech groups.

I haven't coded in 7+ years, but I leverage my computer science background to bridge the gap. I'm more effective due to my tech background, but I hardly ever have expertise in the specific language/tools. I have had success without being an SME of the particular technology.

It should be interesting to see if anyone takes the counter point of view.

Estimation in Kanban?

Before I start, I should note that there is a lot going on in the Agile community related to Lean and Kanban. In case you've been in a cave, you might want to check out this great slide deck by Henrik Kniberg comparing and contrasting Kanban vs. Scrum, or check out Karl Scotland's blog on the topic.

That being said, Anna Forss blogged today about how estimates do or don't fit into Kanban. An excerpt:

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Jump to her full post to see how she answers this question.

Here's my comment on the topic, even if it is a little open-ended:

I was under the impression that estimates aren’t needed as much in Kanban because items are supposed to be closer to being “of similar size”? Looking back to the original Toyota manufacturing process application, this would have been true.

Otherwise, a large item might hang in your work queue for weeks (because it is too large) while small items fly through. If several large items “get stuck” then it might clog the whole kanban system.

So… do you need to estimate to insure that items are small and closely equivalent? (maybe)

This also make the concept of MMF (minimal marketable feature) an important goal when writing stories!

Scrum weaknesses and Potentially Shippable...

Jack Milunsky posted another great article on the Agile Software Development blog about the areas where scrum falls short. It's an interesting read and I encourage you to consume it. I'm a strong believer that Scrum is a great starting point, but an agile transition shouldn't end with it.

One point I didn't agree with though was this:

Potential Shippable code - what does this really mean?
Most Agile thought leaders define the output of an iteration as an increment of potentially shippable code. And more often than not, it appears to be acceptable (please tell me if I perceive this incorrectly) that this potentially shippable increment of code is not actually live production code. And therein lies my beef with Scrum.

Here's the response I left:

We have to remember that when "potentially shippable" was created as a concept, we were combating waiting months or years to ship a product. In large enterprise environments, this was an even larger/longer problem. This new concept embodied the idea that we could stop at the end of any 1 month iteration and have something working (and probably of value).

Since then, the industry at large (due to the internet and companies like Google) has embraced eternal betas, imperfect software, and constantly evolving software focused on constant value. Within agile, we've seen a migration to iterations under a month. I believe it is time to rename this to "proven shippable". This is the compromise between Jack's comments and the enterprise's needs. Enterprises build large solutions to large problems and they understand the needs of the market. When a complex domain (like banking or healthcare) already has mature software solutions, you know your product won't displace the competitor's software after the 2nd or 3rd iteration. There is effort to marketing and advertising new products. It is important to have a release cycle and the power that comes with it. You can't just dribble out small changes every week and expect to catch the market's attention.

This is why I think that in small continuous flow shops, I agree with Jack's done = production use. But in large shops with large customer bases, you might need to allow the business and market determine when to take on the new release and not force it on them. If your releases are compelling enough, they will migrate (VersionOne has mastered this!) In this case I don't think your done criteria can be production.

Thus, I propose -> "proven shippable". This means you have shipped it to somewhere external to your development group that is a proxy for the customer base.

Agile Maturity Model & Scrum Success Story...

I wanted to make sure my readers had the chance to review these two links, so I'll share them here:

• Ryan Martens over at Rally talks about IBM's (Scott Ambler's) proposed Agile Maturity Model. It's a good read, I agree almost perfectly with his statements. My take on these topics is this: once you box and define agile, you lose the magic. Agile is about inspect and adapt. Definition for the mainstream removes the adapt part (it just sets a straight goal) and then inspection is unnecessary because the definition allows you to falsely believe you've attained your goal. (Hint: The goal keeps moving as you get better!)
• Samir Bellouti posted a great experience report about his team's successful first year of Scrum implementation. I'm no longer a strict follower of Scrum, I tend to blend various agile approaches, but I believe that if you don't have a coach or resource to help you through implementation, then Scrum is a great recipe to start with. It's most documented and supported and will allow you to figure it out on your own with the published works available. This story is an example of how it SHOULD turn out and notes the value provided to the business.

Folks, agile is not easy! Just like dieting to lose weight, going agile is hard work for a more efficient and valuable outcome.

Great stories...

If you haven't seen these great blog posts you should check them out:

Lean Team Software Process by Corey Ladas

snippet: An alternate metaphor for software value is a refined substance, like gasoline or ice cream. The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system. This view suggests that software has no more customer value than the sum of the scenarios that it supports. Then there is no bright line that defines “complete”, there is only relatively more or less value delivered. When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product. Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Metrics, Schmetrics II by Matthew @ Creative Chaos

snippet: All of those examples are fungible - a gallon of gas can be traded for any other gallon of gas. A penny saved is a penny earned. They are all the same.

Yet test cases, lines of code, these things are not the same. You can have a test case that takes two hours to set up, or a half-dozen similar ones you can run in thirty seconds.

Scrum vs. Kanban by Mike Cottmeyer (ignore the Idol intro and title at the beginning)

snippet: I think that in some ways Scrum is hitting a wall because some of us think that Scrum is the answer to everything. Is Kanban the new answer to everything? Is it going to replace Scrum and XP or DSDM or AUP or Crystal? I can't even imagine how we can have these conversations without understanding where and when is the best context to apply these principles. I feel like a broken record but there is a time and place for all these techniques.

Help! Our estimate was off by a lot!

Another LinkedIn discussion, this time the question was along the lines of estimates that turn out to be incorrect. In this case, the person asks what the team should do when something estimated at 6 hrs turns out to actually take 26 hrs.

Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.

Is there any way to handle this issue? It is ok to pop out some stories in between sprint?

Most of the initial responses focused on the fact that estimates are always slightly wrong and that this error will normalize itself out. One person before me suggested mid-sprint correction with reflection during the retrospective. I agree that trends of estimate problems should be reviewed, but the real question was... what do I do right now in the middle of this sprint?! My response:

If you uncover something mid-sprint where your estimate will be 4x greater than originally thought, I would assume you have uncovered an impediment or complexity that was unknown during planning. This will happen from time to time, even on a mature team (otherwise you might not be doing difficult enough work!).

My advice would be to pull the product owner/customer in immediately. They need to understand the issue (and hopefully the cause). They need to decide if that story is still important to them at that cost. They may want to descope it knowing that everything else in the iteration is more important than that one thing. Or... they may tweak the requirement to get the majority of it and work around the problem.

I follow most scrum ideals, but I don't believe that a sprint's scope cannot be changed mid-iteration. (Actually, I'm doing a Kanban/Scrum blend now). It makes sense to re-evaluate when these things happen because the team has to remember that the largest goal is delivering the right business value. Delaying multiple expected items for a single item is a decision that should be left to the product owner/customer.

I'm curious to see what others add to the discussion thread. Unfortunately, I think most people are focusing on pure Scrum (ignoring other Agile flavors) and are assuming this is an immature team. I don't know if that is the case for this person or not.

The Support Team...

An Agile LinkedIn group participant asked how to run an agile team focused on supporting a product that a different team built and delivered.

First thought... who decides which resources get the glory of working on the sprint team that creates and delivers features and business value each sprint vs. the hazing of working on the support team that fixes the crap. I really hope that if you decide it is necessary to split into these two groups, you at least flip flop the assignment or slowly rotate resources between teams to make it feel like one big team. Otherwise, the supporters will only be mad at the creators and you will fall into the typical us/them developer/QA turf war.

A sub-question was posted on how to handle "critical" issues. It was stated, these are the things that are more important than anything the sprint currently being worked. Several points here:

• If these critical issues are bugs or defects, and they happen often... then it's time to have some courage and discipline and go upstream and ask difficult questions. WHY are these things happening, and HOW can they be reduced in frequency? Instead of adapting to handle them, go to the source and stop them. If you can't because "they" are a different group under different management, then you aren't in an agile organization.
• If they don't happen very often, then this is a simple answer. Let the product owner decide whether the item is more important than items currently in the sprint. If it is, then it should be estimated and should displace a set of stories that are lower priority and of equal cumulative value.
• Work one week sprints. As a support team, you need the ability to be more flexible. Shorter sprints allow for quicker reaction and re-prioritization. Also, work can't stagnate without being noticed. Deployment is quicker (although you might deploy daily and not wait for the sprint end).
• Think about applying Kanban. Loosen the strict requirements of scrum and use Kanban to drive how many things you have in flight at a time. Use iterations as a measurement and assessment tool, and use Kanban to drive priority and work. Walking the board will put the daily focus on priorities.

I know that last bullet blows some of the Scrum rules out of the book, but his questions were Agile questions, not Scrum questions. So, I went with the blended solution approach.

Scrum does not kill the need for a PM...

Jack Milunsky posted on the Agile Software Development blog a great 2nd part article about change caused by agile. I agreed with many of his ideas and points, but one of his statement rubbed me the wrong way. Here is his statement and my response:

You said, "Scrum essentially does away with the traditional Project Management role."

Why do I keep reading this everywhere? Why is this becoming a standard statement? Is it really true?

I not sure it is always true, I think it is dependent on the environment.

Example:
My first experience with Agile was at Siemens Medical. On our "project" (product release effort) we ended up having ~5 scrum teams across India and Philadelphia. Each had a scrum master who spent a lot of time focusing the team on the agile transition and the process. We still NEEDED a PM to help coach and guide the teams, scrum masters, and product owners. In this case, the PM and PO (two separate people) were very helpful in guiding the 5 teams to draw their slices of their sprint backlog from a single unifying product backlog. I do not know how we would have done this without a PM and PO. Note: our PO was a person from the clinical domain, I would not have expected him to also fill that role. The scrum master role was focused on helping the team transition and function daily, the PM role focused on interfacing with the company and handling reporting, staffing, metrics, and buffering us from the company (we had 2500 people on our campus alone). The PM (with the PO) was the single voice of the 5 teams to the company, the scrum masters could not have done this.

So the question is... is this an issue of Agile at scale, or was my experience unique due to the domain? Either way, I argue it is not a foregone conclusion that scrum does away with the PM role.

Sorry Jack, I wasn't picking on you specifically... you were just the third or fourth person who said that this week.

ScrumAnd, not ScrumButt...

Repost: Ola discusses the difference in climate, attitude, and outcome when we switch a conversation from "Yes, but..." to "Yes, and..." Not only is this an interesting coaching/team culture thought, but it ties in well with the ideas around Scrum, Agile, and the different disciplines (and how they can be combined).

I believe ScrumAnd already exists. Under a different name though. It’s called eXtreme Programming. It’s Scrum and programming practices. Now you might say. ‘Well, Scrum deliberately says nothing about programming practices. You can use Scrum to plan and execute anything’.

Yes, that’s true and that’s the problem. People are now cranking out crappy code at least twice as fast as they used too.

Read the full post "What About ScrumAnd" here.

Unlearn what you have learned...

For people right out of school... no problem. For those of us who suffered through years in the workforce, I agree with Nimesh that going Agile is somewhat about unlearning what we have learned.

9 good points in his article on the Scrum Alliance site found here.

RP: 10 activities of PO

Repost: From Jack Milunsky on the ASD blog, post about the 10 activities of a Product Owner. Bullets summarized here, read full post for details.

1. create/maintain product backlog
2. prioritizes backlog
3. assists with epics->story breakdown
4. conveys sprint/release goals
5. represents, interfaces, engages customer
6. participates in standing and sprint meetings
7. accepts/rejects sprint deliverables
8. can redirect team/project with each sprint
9. communicates status externally
10. can terminate sprint early if drastic change is needed