Agile Advice: Software Archives

May 24, 2007

Scrum Rules

Recently in my ScrumMaster Certification courses, I have been ending the course with a list of the rules of Scrum. This list of rules is based on my understanding and practice and may not be 100% the same as that found in the Scrum books or in other Scrum practitioners' models. Nevertheless, I just recently checked it against some other online reference material and it seems like a reasonable list of rules. I am interested in any feedback or variations or disagreements...
[Updated: 20070922]

Without further ado, here they are, categorized into Required Rules, Basic Rules and Optional Rules, plus a downloadable PDF version.

Required Rules to Start – the “Agile Skeleton”:
- Full-Time ScrumMaster Identified and Team Members Available to Do Work
- Team Agrees to Demonstrate Working Software in No More Than 30 Days
- Stakeholders Invited to Demonstration

Basic Rules of Scrum to Implement As Soon As Possible:
- Full-Time Product Owner (with Expertise and Authority) Identified
- Product Owner Works With Team and All Other Stakeholders
- Product Backlog Created and Managed by Product Owner
- Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
- Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
- Regular Sprint Length (no more than 30 days)
- Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
- Sprint Burndown Chart
- Team Room with All Needed Equipment and Supplies
- Retrospective Meeting for Process Improvements
- Definition of “Done”
- Commitment Velocity Calculated (from Sprint Backlog Estimates)
- Team Size 7 +/-2, Maximum of 12
- Cross-Functional Team Including ScrumMaster and Product Owner
- Team Self-Organization - Team Members Volunteer for Tasks
- ScrumMaster Tracking and Removing Obstacles
- Team Safety – No Interruptions to Team's Work During Sprints
- No “Break” Between Sprints
- Sustainable Pace - Timebox Effort, Not Just Schedule
- Quality is Not Negotiable - Defects Go on Top of Product Backlog

Optional Rules of Scrum to Implement Depending on Context:
- Test Driven Work and Continuous Integration
- User Stories as Product Backlog Items (As a I can so that )
- Project Burndown Chart
- Release Burndown Chart
- Planning Velocity Calculated (from Product Backlog Estimates)
- Scrum of Scrums for Multiple Teams
- Canceling the Sprint Early
- Financial Modeling for Product Backlog
- Sprint Backlog Tasks on Big Visible Chart on Wall
- Backup Product Owner Identified
- Team of Volunteers - Self-Selecting
- Rotate the ScrumMaster Duties

And here is the downloadable version of the Scrum Rules Cheat Sheet [pdf].

Finally, you can purchase a poster-sized version of this from Cafe Press AgileAdvice Shop for $22.99.

Posted by Mishkin Berteig at 03:01 AM | |

April 19, 2007

Effects of Defects: Grey Scope Creep

Is boosting productivity simple? Yes! Just cut code! One problem here. The gap between code complete and feature done is bigger then it appears. That was my thought as I was looking at statistics.

Reposted [and edited - Mishkin] from www.softwarefrontier.com by Dmitri Zimin(e)

On average, a developer cuts 300 lines per day, some true heroes claim more. This “productivity” comes with the price of 100 defects per 1000 lines of code. Finding defect and fixing it is on average 4 to 16 hours [1] [2]

Do the math: Your star developer produces 500 lines a day. This creates up to 80 hours of extra work to himself, the dev team and their tester buddies. 10 days! I call it “grey scope creep”.

At first, these statistics seems totally off. But you can surely remember such a super-star code monkey? You surely know a few. Now go over all these steps to fix a defect: cutting the build, installing it in QA, testing, finding the bug, writing a bug report, assigning it back to development, reviewing, trying in vain to reproduce… “Works on my machine”, sending it back to QA, and finally, after a couple of round-trips, it’s fixed. Then regression sticks out its ugly head, and the high 16 man-hours per bug looks too good to be true.

So, is boosting productivity simple? Yes! Less bugs in, more bugs out! One problem here. But enough on problems, let’s get positive and move on to how fight grey scope creep.

First, if these superstar developers only care about the joy of cutting code, not shipping the software, they get the boot. Don’t regret it, they produce more work then they get done. It is not about developers developing and testers testing. It is developers and testers working cooperatively to ship software. We've got no space for local optimization.

Second, good software practices are to the rescue. Pair programming, design and code reviews, test driven development, etc… They surely slow down the LOC/day pseudo-performance (less bugs in) and reduce the number of defects. Pair programming by itself brings 15% less bugs, with healthy 15% slow-down of LOC performance [3].

Third, redefine “done”. Fresh features are marked done, and then disappear somewhere in QA to eventually fire back at unknown time with unknown bugs. Grey scope creep. Stop it. Instead, insist on taking less but making it “done” within an iteration. Done reads fully developed, thoroughly tested, debugged, fixed including regression, and accepted by product owner. If this brings development to a deadlock, it’s one of the two. You may be blessed to fail faster and cheaper. After all, if you can’t get “done” just one feature, how would you ever be done with the entire project? Or the team overcomes the crisis and changes the working habits. The shortened feedback loop and fixing bugs as you make it leads to less time per bug fix. The grey scope doesn’t creep beyond the iteration. Problems become obvious early enough to to deal with them.

Finally, until you fix the grey scope creep, your estimations could be off, up to 10 times! Measure well.

So, is boosting productivity simple? Yes! One problem here. Trying to address it may expose the stakeholders to too much truth about the state of the project. Figure out how to deal with this truth. Or wait to my next blog entry... I have some thoughts about this too.

Posted by Dmitri Zimine at 09:42 AM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.

1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.

2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.

3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.

4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.

5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.

6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.

7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".

8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.

9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.

10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.

Posted by Mishkin Berteig at 06:32 PM | |

December 22, 2006

Technical Debt

Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team's work become a "debt" that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are...

Debt is sometimes useful. Financial debt can be used for risk reduction, investment, and emergencies. But it can also cause problems. Too much debt becomes hard to manage. If debt maintenance costs more than revenue (minus other expenses), then you're going down!

Technical debt is a little different than financial debt.

Suppose I went into a boardroom full of high-power executives for some large company. (Never mind how I got there.) And I pitched this fabulous idea: I'll give them a bunch of money for them to use for operations, expansion, whatever. All they have to agree to is that I choose the interest rate when I ask for repayment... trust me!

I would be thrown out of that room so fast!

That is what we do when we encourage teams to take on technical debt.

There is no way to know the interest rate on a defect. Part of the cost of a defect is obvious: how much time and materials will it take to repair the immediate problem. (Although even that is often hard to measure.) But there are also lots of non-obvious and probably non-measurable costs. How much effort will it take to get to the root cause of the defect so that it doesn't occur a second time? How much will it affect our "goodwill" and thus reduce further and repeat sales? How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs?

In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.

November 15, 2006

The Case for Context Switching

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in "From the 'You Call this Agile' Department":

Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.

Okay... I'll bite.

Let's look at that argument from the perspective of the sales person first since that is where Joel's concern starts:

The Sales Guy Perspective

"I need the 'ezhibal' feature now! Big bucks coming soon if we can get it now."

Let's suppose that this urgent email has come in somewhere near the start of our two week iteration. The normal response to this in Scrum is to push back a little. The ScrumMaster says something to the effect of: "Look if you wait 7 days we can put this on the top of the list for our next iteration."

First reaction, and it's a normal one, is for Sales Guy to freak out. I've actually heard people saying things like "You're going to lose your job over this! I'm getting the VP involved and he's not going to like it" and then they stalk off to find the big dog to come and bark at us. Anyway, let's pretend that the Sales Guy is willing to be reasonable and not instantly escalate the "problem". So what he actually says is: "Look, this is super important, it'll probably only take a few minutes for us to talk about it and then we can figure out how long it will take to fix. Let's just do a quick phone call and yadda, yadda, yadda, blah dee blah..."

Enough of the Sales Guy perspective.

Nowadays, if I'm in this situation, I do a value assessement. I tell the team to keep working on their plan, nothing's changed yet, and I sit down with Sales Guy and the person who's sponsoring the current work and we start a discussion about the options of which there are really only two that work in Scrum:

Stay the Course
Cancel the Iteration

First, let's talk about how we decide which option to take. Then we'll talk about why.

Deciding on the option is easy. You look at the value of the work currently being done and compare it to the value of the work that Sales Guy needs. You take into account probabilities. If Sales Guy doesn't have a signed contract, then it's hard to day if there's going to be any real revenue from the 'ezhibal' feature. Still, you might be able to do an assessment of the probabilities based on your level of trust and history with the client, etc. You also need to take into account the time value of money. Does delaying the current work have consequences for another client or stakeholder? What is the cost of those consequences.

This is a relatively simple cost/benefit analysis and comparison. If you're not comfortable with money and numbers and spreadsheets, you better get comfortable!

Okay, so we have a way of comparing the two bits of work. Now let's look at the two "allowed" responses and a third "bad" response.

Stay the Course

Turns out that the potential benefit of the stuff Sales Guy wants is not quite as high as the potential benefit of the stuff that Suzie Stakeholder prioritized for the current iteration. Well, that's easy. Put the request from Sales Guy in our prioritized list of work and get to it when there is an appropriate level of benefit relative to the other work.

Cancel the Iteration

The stuff Sales Guy wants is super-valuable. So let's get the whole team to stop what they are doing and everyone supports this very valuble work. Stopping the whole team is appropriate because obvioulsy, the stuff they're working on isn't as valuable. Oh, and because we treat a team as a unit in Scrum. And because the team needs to commit to work, not individuals. This isn't so obvious... more later.

Peel Sarah off to do the 'ezhibal' Feature

This is what normally happens, and in a "normal" non-agile environment, it's probably okay. In a non-agile environment, Sarah hasn't made any commitments (she's been forced to agree to dates and scope, etc., but she hasn't made a commitment that she is empowered to live up to). So if she goes off and does this one little thing, it probably will be just business as usual. In an agile environment, the team has made a commitment and doing this work this way invalidates the team's commitment.

Why do we do it this way? The main reason is around trust and commitment. Yup, it's that soft icky stuff that we're so incredibly bad at that customers think that bugs are normal, that management shoves the kitchen sink into projects in the frustrated hope that they'll get something out of the IT team at the end of the project. Sound familiar to anyone?

Anyway. An iteration is a commitment. It is a firm and solid commitment. The team as a group of smart and honorable people is making a definite commitment to the rest of the organization to get a certain amount of work done in a fixed amount of time. In return, management is agreeing to give the team every support in reaching this commitment. When a team is new at this, they might get it wrong. But having done this with dozens of teams now, I know that after a few tries, the team gets the hang of it and commits to appropriate amounts of work, and management provides appropriate levels of support.

This commitment is essential for developing trust. And anything that comes in the way of the team meeting its commitment is considered "BAD". An obstacle to do away with.

This is interesting, because Joel's second example is about defects. And I strongly agree that defects are "BAD" and need to be dealt with at a very high level of priority. The reason is simple: they prevent a team from meeting its commitment.

One team I was coaching was constantly bombarded by these types of it'll-just-take-a-few-minutes-need-it-asap requests. They had many stakeholders and very very limited resources to service these requests. They had several small projects that were taking literally years to do because they couldn't get enough concentrated time on any one thing. This was considered normal and good in their environment.

The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization. For us geeks, we all know that local optimization is something to be avoided if possible. We climb a peak only to discover that we have to climb back down a ways to get up to the higher peak we now see is next to this one. We climb up that one only to discover yet another higher peak even further along thus requiring us to climb down and up again... When really what we should have done is stepped back a ways, looked at the lay of the land and said, "hey, that peak over there is the highest of them all, let's go climb that one."

Scrum helps us avoid local optimization by forcing all feature requests for a team to be prioritized in a list of work, and by allowing the team to complete small pieces of work so it actually gets _something_ done that you can learn from.

Joel said:

Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.

True enough! But it also demonstrates a serious lack of understanding about what is being done in Dmitri's example! First of all, without being agile at all, it is possible to switch from 18 month projects to two week projects. Both can be bureaucratic as you please (well, actually, there's only so much bureaucracy you can cram into two weeks and still get something done). The shorter projects will allow you to be much more responsive to customer needs... by definition!

So what happens when you add in all the other things that agile really is about? Transparency. Truthfulness. Creativity. Learning. Meta-Learning. Prioritization. Self-Organizating Teams. Eliminating Waste.

Well, first of what you get is something that's damn hard to do right. It goes against almost everything we've been taught to do: the extreme of heroics of the extreme of careful planning and process.

Secondly, what you get is something that needs safety zones and meta-rules. Like mutual, freely-given, team-to-stakeholders commitment. Like assuming positive intent.

And thirdly, what you get is an environment where not only is the business getting what it needs more than it used to, but also, the team likes working with the business, and the business likes working with the team.

I admit that the point Joel is making isn't too different. Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.

Posted by Mishkin Berteig at 04:13 AM | |

August 28, 2006

Nice Interview with Mary Poppendieck

Mary and I worked together for a short time almost two years ago now. When we worked together I was impressed by her honesty, insight and wisdom. Here is a brief on-line interview she has done. It is focused on software development, but many of the ideas she discusses can be easily translated into other types of work.

Posted by Mishkin Berteig at 10:13 PM | |

March 16, 2006

Unused Features

Software projects have a really bad record. Here's a part of that bad record: on average, 45% of features delivered are never used! This is yet another reason that Agile methods shine: do the highest value work first and stop when you've got enough. Can't do that with waterfall projects!

Posted by Mishkin Berteig at 02:28 PM | |

August 23, 2005

Agile Offshoring References

Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders' attentions on re-examining their core priorities. Where Agile optimizes on "Time to market", the offshoring "over-the-wall" approach to software development seeks to optimize on raw dollar cost.

What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what's out there comes in the form of mini-articles that are no more than promotional ads for X proprietary "agile-offshore" solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.

Using an Agile Software Process with Offshore Development: by Martin Fowler
A look at Valtech's approachfrom within the project. This calls itself a case-study, but no metrics are provided
The sad and understandable ruminations of Jonathan Nolen on his blog, regarding Agile offshoring and his expectations of the project. These attitudes and cocerns are quite common - this is a good poster for the kind of feeling you might find from developers.
Vincent Massol's presentation to Javapolis. No proofs or metrics, though some lessons learned are provided.
A forrester research article on Agile Outsourcing. Note: this is only the abstract - the article is $350. (I should ask for a commission. :)
Some practical advice on agile offshoring from a Thoughtworks fellow.
Good points about customer proxies that are very applicable to offshoring with agile
A very good summary of an ongoing conversation about fixed-bid contracts and Agile. It relates to the agile-offshore issue given that often projects are offshoring because of cost-sensitivity, and are thus fixed-bid.
A look at criteria for choosing offshore partners based on Agile business readiness.
Article by Scott Ambler on agile outsourcing.

Posted by Christian Gruber at 03:47 PM | | | TrackBack

August 18, 2005

Harvard Business Review Article

I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.

Posted by Mishkin Berteig at 10:48 PM | |

August 12, 2005

Just-In-Time Value Delivery and Waste Elimination

Lean Manufacturing

If I am manufacturing computers, and I receive a large batch of CPU's... say... Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.

Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.

Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution

Waste and Inventory in Software Development

Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.

Traditional Software Development Example

Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let's further suppose that ten of these are business-critical features, and that all of the features' definitions are highly market-driven.

So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.

So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.

Lean and Agile Software Development

Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes - say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.

If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be "done", but it's "done enough". Then the team can continue to roll-out less valueable features from the prioritized list.

Market and customer needs volatility

This becomes even more important when we consider the competition's changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or "just-in-time", and they could get high-value changes "just-in-time".

Quality

Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer's desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn't suffer from customers or markets changing their minds.

Summary

Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed - not six months too late.

Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70's and 80's. It is only in the last two decades that, after adopting Lean practices, Toyota's competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don't adapt to just-in-time value delivery - who don't eliminate waste in their processes - will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.

"If you're not on the steam-roller, you're part of the asphalt." - Lighthouse Design, circa 1996.

Posted by Christian Gruber at 01:30 PM | | | TrackBack

August 04, 2005

Just In Case You Haven't Seen It Yet

There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel's writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.

Posted by Mishkin Berteig at 11:41 AM | |

July 23, 2005

The True Cost of Software

From the Link: Calculating the True Price of Software by Robert Lefkowitz -- Businesses have long viewed support and maintenance as essential components of software. Open source business models often focus on charging for support and customization. Is there an economic model that can demonstrate the true worth of a piece of software and the option for support, maintenance, and upgrades? Robert Lefkowitz argues that open source exposes the true value of software itself as, essentially, worth less in comparison to support and maintenance.

Posted by Mishkin Berteig at 04:37 PM | |

May 17, 2005

The Qualities of an Ideal Test

These six qualities of tests describe how to make a test as effective and as useful as possible. The qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym.

Decisive: The test contains all the information required to automatically determine success or failure. Manual inspection of test results is not necessary to determine success or failure. The test is expressed in a way that produces a pass/fail answer rather than a numerical or qualitative result. Decisive tests are often expressed as assertions.

Valid: The test produces a result that matches the intention for the work artifact under test. Test failure indicates failure in the artifact under test and test success indicates correct operation or configuration of the artifact under test. Simply put: the result of a test should be true.

Complete: The test contains all the information it needs to run correctly with a given test harness and work artifact under test. The test performs all activities and provides all the data necessary. The test does not require any input outside of itself in order to run.

Repeatable: The test always gives the same results if the test harness and the artifact under test are the same. The test is created in such a way that the result is deterministic. Even if the system under test is not deterministic, the test should be created to account for that (possibly with statistical analysis) and produce a deterministic result.

Isolated: The test result is not affected by other tests run before it nor does a test affect the results of tests run after it. The test and the test harness work together to clean up after every test is run. A collection of tests can be run in any order and always produce the same results. Any test that depends upon the results or side-effects of a previous test is not isolated.

Automated: The test requires only a start signal in order to run to completion in a finite amount of time. No manual intervention is required after the test is started. Tests that are automated can be put together into a test suite and run one after another without human intervention. Automation of tests requires the creation of a test harness system.

Update 20060106

I've added a little bit more detail to the above qualities. I also wanted to say a few words about my experience with testing:

I first started doing test-driven development almost seven years ago after reading the book Refactoring by Martin Fowler. I picked it up in Windsor Ontario while I was driving to San Francisco for my first contract position as an independent. I had to stay the night there due to the immigration office being closed so I read a lot of the book in my motel room that night. By time I got to California four days later, I was totally convinced that I should be using JUnit and refactoring for everything I did. Fortunately my project was ammenable to this approach. Over the next four months I built a Java JMS layer on top of Tibco Rendezvous. In the process I discovered methods for doing unit tests for asynchronous multi-threaded distributed functionality. And my tests satisfied all the above qualities. I delivered code with 100% test coverage and zero defects discovered until more than two years later when a very rare and obscure deadlock issue was found. Suffice it to say, I was convinced from a quality perspective.

But there is more. To build tests that follow all the above qualities, you need code that is testable. I have come to believe that testability is the most important architectural attribute of code for most software. The implications of having testable code include code that is easily changed, that is verifiable, and that is easy to understand. Refactoring plays a big role here too.

For getting a basic but very practical sense of test driven development, I strongly recomment Test Driven Development: By Example by Kent Beck.

I have also written a couple of articles recently about quality:

Quality is Not Negotiable in which I talk about how to handle defects - by always treating them as top priority work items.

and

Technical Debt in which I expand on this common analogy between lack of testing and debt to show that technical debt is even worse than financial debt.

Posted by Mishkin Berteig at 06:48 PM | |

May 12, 2005

Scrum Gathering May 2005 in Boston - Rough Notes

Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn's presentation on User Stories... but his book (User Stories Applied : For Agile Software Development) is excellent :-)

The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!'s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.

Scrum Gathering 20050511

Companies using scrum: Microsoft, Sun, Siemens, State Farm, IBM, Federal Reserve Bank, Yahoo

Purpose: implement scrum

http://www.controlchaos.com/playbook.pdf

Predictions by Ken Schwaber:

33% of orgs implementing Scrum get most of the benefits – triple the initial productivity
66% will largely fail – software not that important for these orgs
Current software workload will be done by 25% of the staff
Developer will become a umbrella title for software developers – no longer specialized titles
Scrum and XP will be seen as two complimentary approaches that will start merging – may drop these names over five years

At Wildcard Systems, transition from fixed price to time and materials for clients

Bob Schatz – implemented Scrum at Primavera

Recently left Primavera now at Solstice Software

Enterprise Agile – what does it really mean?
“Enterprise”
multiple teams, same projects
multiple teams, multiple projects
implementing across an enterprise
building enterprise applications
building systems to support an enterprise
implementing across geography and cultures
Enterprise Agile is all of these and more

Implementing agile is a culture changed
culture changes are extremely difficult
transitions are different for everyone
Everyone likes change... as long as it doesn't affect them
Two factors that facilitate faster changes
pain of doing it the old way is greater than pain of chang
new opportunity where the old way simply won't work
Other than that
it takes strong leadership, determination, and TRUST
Learn to crawl before you think about walking

(Primavera did it all in a big chunk – WHAT SITUATIONS MADE THIS WORK?)
- amount of pain – about to start a new project – very challenging, big technical hurdles – asked about doing it with just one team – what's the point? - whole org new the pain – let's just get this done – didn't want to compare apples to oranges (agile to waterfall) – decided to switch pains – bob had a management team that he spent a lot of time talking with – management team was absolutely on board – failures have come in places where management is working at cross purposes

Communication
open communications are critical in agile projects
larger, more complex projects require more communication
across organizational lines
frequent customer communications
Coordination
project managers coordinate the efforts of multiple teams
focus on team building and self-managing teams
progress and obstacles must be visible to everyone
learning and knowledge must be shared across teams
Co-location
individual teams ideally should be co-located in team rooms
the reality is that they can't always be
get creative!
Do the best you can and compensate with technology

No silver bullet
enterprise implies complexity
implementing requires leaders, knowledge, skill, and adaptive techniques
one person will not single handedly change a company
a consultant will not change your culture for you
buying a tool will not make you instantly agile
not everyone will read the stack of books you buy them
executive sponsorship and support is needed (DISAGREE? ANYONE HAVE EXPERIENCE WITH THIS NOT BEING REQUIRED?)

Keys to Success at Primavera (100 people in dev org)
sufficient motivation to change (pain)
good coaching from outside
team rooms
town hall project meetings – like daily scrum but from reps for each team
project manager role transition
information radiators
no OT/weekend working – change perspective of managers that OT is good
test driven development
“science fair” sprint reviews
build process
rotating “Scrum Master” responsibilities (after doing scrum for 1.5 years started seeing little hierarchies in teams) – certified ScrumMasters became cross-team coaches
best team performance rewards @ end of each sprint related to performance, scrum compliance, etc.
team-based bonus component (two components focused on scrum plus teamwork)
feature budgeting – work on feature only budgeted time, if over, negotiate with PO (ESTIMATES DON'T WORK regardless of tools)
sprint defect limits (tradeoff in favor of quality)
customer Webex sprint reviews
commitment to learning!
Combination of these things reduced defects by 75% (year 1 1200 to 600 with scrum, year 2 600 to 300 with XP)

What to Expect
resistance – always resistance to change
setbacks
problems
obstacles
damaged egos
unrealistic expectations (kept implementation of Scrum quiet)
difficult personalities
lack of trust

“The Hurricane's” System!!
Ken -> Hurricane -> disaster/destruction -> rioting -> calm -> Ken
Ken tells it like it is
people get freaked out

What you will get
well-respected motivated focused workforce
creative energetic learning environment
everyone focused on achieving goals
ability to meet commitments and be flexible
high value products
a disciplined repeatable approach to building software
cross functional teams that understand technology and business value
involved satisfied “customers”
Academia does not model cross-functional collaborative team work (e.g. No collaboration with business school)

What can you do?
have a vision and sell it
identify pain points and don't be afraid to try something different
openly discuss behaviors and challenges
look for the “real” issues, not just what people talk about
identify champions and leverage their power (people who influence others – make sure they're on board)
educate people outside of development and involve them in the process
brush up on your influence and negotiation skills
use the language and ceremony of agile
reward good behaviors, celebrate success
work the bad attitudes out of the system
don't sweep them under the carpet
be patient, persistent... don't give up!

What would you do differently
everyone makes mistakes
communication as a leader could have been better

How did you set expectations?
upper management already had low expectations
middle management was told that there were no expectations for the first few sprints

Add process/environment/team improvements to the backlog – someone has to pay the price for it. Everything goes on the backlog! Nothing is ever perfected – always changes and improvement.

Made mistake – Scrum of Scrums was institutionalized with responsibilities – but this caused power and conflict issues – eliminated this and move to town hall meetings (Scrum of Scrums as a meeting rather than an organizational structure)

Times for management feedback
sprint planning and review
special meetings (maybe triggered by observation in daily scrum)

Core of stubbornness, courage or stupidity.

Esther Derby – Panel Discussion of Agile Change: Building the Self-Organizing Enterprise

Tim Bacon – from UK – ScrumMaster and Coach
Jeff McKenna – Original Builder of Scrum
Diana Larson

Tim:
transition to XP since 2000
deal with personal and small group level
culture about how people interact – congruence between thoughts and action – values

Jeff:
1991 Scrum
Agile before that
primarily with small teams but up to 80 people
difficulty – getting people engaged – people don't have responsibility for the things they do – power to make changes in working lives – very difficult
Diana:
culture is the stories we tell ourselves about ourselves
changing language
systems level of change - “freedom's just another word for nothing left to lose” J. Joplin

Deb Hartmann
are there places where we shouldn't bother trying to change?

Yes, but depends on how you like to spend your energy.

Jeff:
if entire org is saying “no” then listen, but sometimes people say “no” without knowing what they are saying “no” to
as a consultant: there are times when you say “I don't want to do this anymore”
if motivation is there “I want to change” then it is easier

Diana:
if some say “yes”
“see where the buffalos of change have roamed before and see what kind of a trail they left” - indicators of where things might go in the future
ego involvement – significant influences who have lots of investment in the way things are can prevent change – or need someone who can move them out of the way
How do you make org change stick?
You don't
orgs keep changing – not really a new status quo, just a breather

Tim:
you can always change starting with yourself
personal integrity and desire to go to work
sometimes need to change other people to keep integrity

Jeff:
find out what people mean by “being agile”
explore what they mean

Going from waterfall to scrum – is there a smooth transition?

Diana:
define “smooth”?
People go through change in different ways – lots of models of change
resistance can be characterized as wanting to hold onto something of value
people need to see new/better value in the destination
may be emotional
the transition in people changing is chaotic and it is hard to do smoothly
some people are not set up psychologically to make a smooth transition
can't completely make transition roughness go away completely

Jeff:
some orgs are easier than others
some orgs have a culture of change
2nd order effect
need some success with change
gain some power to make lives better
rank and file are often pessimistic

Tim:
uncover the pain that is already there
uncover the good things

Ken Schwaber:
a few years ago Martin Fowler: not going to try help unless the org is a train wreck, without hope
now seeing large orgs investigating going agile because of agile's successes
sitting with CEO of corp that want's to go agile
how can I determine if this is even worth doing?
What are some yes/no questions?

Diana:
what types of change and how did they go?
What is it like when someone needs a change from facilities?
How work with HR when needs to be an adjustment?
How do the support systems support the org?
Is the org capable of making a container?

Jeff:
find out where the pain is? What is agile going to address? How is he/she thinking about it?
V.P. Of large company – 2 hours
6 what if's suggested
kept saying couldn't do it
left (maybe someone else could do it)

Tim:
litmus test
looking for intellectual curiosity
actively asking questions
seeing possibilities as you provide suggestions, description

Esther:
what are you willing to do to support this change?

Craig Larman:
ask CEO what do you know about agile? Pair programming
Customer in Scandinavia
successful scrum project compared to other projects
head of project leaving to go to another company
other PMs didn't know about this successes
How do you sell internal success?

Diana:
retrospectives at the end of all projects
what are the root causes of success, not just failure
how do we spread the word?
Risk associated with having only one person lead something like Scrum
need to make explicit the job of knowledge and skills transfer to as many people as possible
e.g. Language “pairing” vs. “shadowing”
use newsletters, brown bags, etc.

Tim:
a big part of all our jobs is to sell what we do
all heard of failures from the inside, but seen as successes from the outside
need to make sure successes are seen as success from the outside
use networks of people
if we don't have the networks, find the “connectors” (The Tipping Point)
secretaries
long-timers
bar, cafeteria

Jeff;
Guerrilla techniques
information radiators
celebrate when work gets done: use a bell
team loves the bell and gets done
other teams ask – what's going on?

Can this be done from a grassroots level? Overallocated people, management confused. Really struggling. Wholesale change is impossible. How?

Tim:
yes

Jeff:
Pete from Yahoo! Will talk about this
warning management
team may have self-starting ability
may bring someone in – should start working on management immediately
technical side can improve team very quickly
constraint moves to management and planning
management will stop work if not ready
management can no longer blame dev for failures
can go higher in management hierarchy

Diana:
start with one team and work from there
team has to manage their boundary between themselves and the rest of the organization

Tim:
we tend to lack courage when implementing from the bottom up
courage is the most important
“be the change you want to see” - Gandhi
there is a lot of fear about change upsetting the status quo

Mike (?):
works outside of development
what are the upside risks? Success can kill you – what happens when you are successful and the org starts to think about institutionalizing Scrum? How do you take this to senior management? Expectation management? Transition and scaling? Lots of cutting of admin work – don't need a lot of middle management to get stuff done.

Diana:
doing self-org teams for 20 years (*********************)
come up against: managers take two stances:
get worried and mess about
abdicate
BUT
role needs to change
what support do these teams need?
Put on workshops about how leadership shifts in this environment
planning going away
resource management, championing, boundary, facilitating all becomes even more important
requires professional development on part of managers

Jeff:
managers who pay attention know they have to learn and improve
always opportunities for improvement
what goes through the membrane between group and rest of org
sole job to manage membrane – 5 to 10 visitors a day
org context
boundaries change and move
new container forming outside of original group
Keep aware of org context and work with that

Tim:
Bob Schatz – managers have an identity problem
transition to leadership – have courage to have vision and lead
subtle
invite senior people to see the teams and join them
always work for these people to do in the team

Bottom up implementation – management happy, later ask about working more hours and weekends to get more work done? What about managers that want to squeeze their people?

Bob Schatz:
OT/weekends lowers quality – period.
Use that quality price to drive behavior
productivity drops because of quality problems

Tim:
find these managers and get them to propose this to the team
team that has successfully transitioned will make reasons for not doing this very very clear
team will supply questions to the manager

Jeff:
just ignore them – worked well
manager broke the team up into two pieces
long hours team velocity went down
normal hours team maintained velocity

Diana:
if question comes up because underlying belief not working enough hours
could be something else going on there – and underlying personal dynamic
could suggest other experiments

Not necessarily that somethings not working. Question about increase productivity based on hours.

Diana:
recruit someone to be team champion
that sort of question can be directed to champion

Jeff:
medical community research about long hours being bad for productivity

Tim:
analogy:
mechanistic thinking
people are machines?
Factories don't run machines at 100% utilization
Lean Software movement
Theory of Constraints
people aren't machines

put it on the backlog as a problem:
how to increase productivity by 25% without increasing manpower

Tim (?): manager may be asking for something realistic

Brian (?): what about external customer who says we're not doing agile. How do we help our customers to adopt this? E.g. A client that has contracted for work.

Jeff:
what do you mean by customer?
Is your business taking an external stance on agile?
Boundary is the organization
can have waterfall relationship to client and work agile inside
may have waterfall embedded in law

Diana:
are you asking about influencing the culture of an industry?
Invite them in to be involved with the process as much as they can stand
might not be very much at first
someone internal must become a domain expert and act as customer proxy

Jeff:
start by inviting to monthly demos (relatively easy)
invite them to come more frequently
like teaching children
go visit customer

Tim:
changing relationship to customer is sometimes about asking them to give something up
have to articulate what they have to gain

Ian: how to reward agile teams to get the best out of them? Reward according to influence not control.

Tim:
“Punished by Rewards” - carrots can be just as damaging as sticks
fun work can be its own reward
agile makes work fun again
extrinsic rewards may be an indicator of other problems

Diana:
frequent small rewards better than large infrequent rewards
large cumulative effect
Esther:
worked with team that received huge financial bonus
bonus was nice BUT
want recognition and notice from managers at a personal level

Jeff:
rewards for goals set by someone else is a problem
e.g. Sales quota had no connection to work in field

?: Starting from top down? What are the top three pushbacks from dev org? How do you overcome them?

Diana:
manage your own expectations
imposing change is very difficult task
frame it as an invitation

Jeff:
“yet another change”

Diana:
varies from org to org depending on culture
e.g. “flavor of month – wait it out” passive resistance

Jeff:
keep working the way I always have

?:
working cross functionally is resisted very strongly
want to protect specialization
iterative may seem less efficient locally
Solve: team building, coaching, build on initial successes
First line management team has to buy in
some people will have to move out of the organization

Jeff:
do lots of educational work
find pain points before imposing solution

Ken Schwaber:
very uncomfortable
teams for X-functional
lots of releases
management questions about jobs
power prestige
get people to talk about their feelings and facilitate solutions
notice the problem and facilitate talking about problems

Tim:
fear comes from responsibility for things that were formerly hidden
now get to own solutions

?:
org change
need to paint vision of new organization
resistance comes from what needs to be given up?
Self-image might need to be given up

Diana:
territorialism
prestige
relationships

Jeff:
paradigm shift – whoop de doo
10-20% of people will not change
some people will have to leave the team

?:
Executives have reposed the question:
how do I facilitate a bottom-up

Mishkin:
key driver metric – top down

Tim:
initial response will be emotional

Diana:
Fast Company article “change or die”

Jeff:
limbic system seat of emotion
decisions are made by this system not the rational side
allow people to use much more of themselves

Roger:
inhibitor to change: the old plaster syndrome
things go wrong, put in a solution, solution is institutionalized
have to deal with all the injuries of the past

What about Some Good References for Org Culture and Change? Self-promotion is okay!
-

Tim: Fearless Change: Patterns for Introducing New Ideas
Jeff: Leading Change , The Heart of Change: Real-Life Stories of How People Change Their Organizations
Bob Schatz: Managing Transitions: Making the Most of Change
Diana: Surviving Transition

?: more about cultural changes for creating team rules.

Jeff:
take over conference rooms
build a relationship with facilities
give team both common area and privacy – gradually spend more time in common

Tim:
might be about owning tools

Jeff:
keep separate tools for email etc.
dev machines don't even have personal logins

Brent:
Q&A session to HR people
dealing with emotional level
some who were most concerned went to HR directly

Esther: one sentence of advice:

Jeff:
Pay attention, watch observer, get awareness up

Tim:
be yourself and allow others to be self

Diana:
be patient, positive and don't give up

Pete Deemer From Yahoo!

History @ yahoo! - founded in 1995
Show up at work and just build stuff
No cubes
Until late 2000
Can't spend anymore
Impose control
Hired consulting firm to impose control
The waterfall for 4 years
Last September – Tobias Mayer – organized brown bag by Jeff Sutherland
Email went out
Pete attended along with 100 engineers
Two hours – blew off meetings
We all have “muscle memory” of small nimble projects that just worked
Pete invited Jeff S. to executive team meeting
The execs often do know what is going on
Potentially revolutionary
Exec team said “ya!” - method to madness that we used to have
December groundswell of engineers and executives – never happened before
Six project teams wanted to start
Esther Derby, Mike Cohn, Paul Hodgets brought in to inform
Four teams left
Deal: support in every way needed in exchange for completed training, coaching, one sprint followed religiously then choose
Scrum pilot program started in early Feb.
Tried bribing Ken, he recommended Paul Hodgets
Paul is light touch, close to teams
Mike Cohn – like a football coach
End of first sprint did survey (anonymous)
Team members and managers
90% response rate
Amazed
First sprint really tough...
but there's something here
How much done, cooperation, quality of work life all had substantial improvement
Didn't want to stop
Quote from manager who was sceptical “I don't know how they did it but what those guys accomplished was remarkable.”
Word spread
More teams wanting to do this
Brought in Gabby Benefield
Head of Scrum practices
Now we have 8 teams + more in the queue
From six months so far -> 15 observations for big companies
1.start with the teams that want to use Scrum – scattered seeds of knowledge widely and watched for the seedlings – everyone on the team must be at least open to it working – skepticism is healthy
2.call it a pilot program – we're not migrating to anything – creates air cover for the messiness – purpose is to learn the lessons – never stop being a pilot – stop when no more teams raising their hands – then examine why – teams that raise their hands have the most pain – Yahoo is classic matrix organization with functional silos – what about interaction between agile and non-agile: non-agile teams become enthusiastic about moving to agile
3.change is scary to many people, Scrum is really scary – resistance is “pre-conscious” - presented as common-sense practices that teams choose to take on – not management forcing it – all of this is about people – people change at different speeds – Scrum is like Indian food: some will love it right away, some will need to try it a few times – some of the biggest skeptics have evolved into biggest supporters – actively managed this – ground the exercise in honesty, openness and realism – gives people room to change their mind – don't create us vs. them
4.Patience is a Virtue – err on the side of rolling out fewer teams and spending time getting it right – every team has had issues – don't risk over-extending and having it collapse – at start many more evangelists for failure and news of failure spreads quickly – over budgeted for working through systemic issues that are made visible in teams – what is us, Us and Scrum
5.Find the middle path philosophically – scrum pragmatists – revolutionaries tend to be the purists – incredible passion – but also they can feel anxiety as transfer from guerrilla warfare against the system to being the system – how to keep the purists involved – revolutions eventually become mundane reality – people are messy, scrum is messy – no utopia where things work perfectly – pragmatists are very effective at carrying this out – but prone to compromise and corner-cutting – creative tension between purists and pragmatists
6.Set a high bar and set low expectations – force teams to take personal cost of training – very hard work, very expensive, may not work for you – people know when they are being sold – lots of pain and work moving a team to scrum
7.Scrum is hard – surfaces lots of nasty stuff – every pilot has had to deal with some big nasty issue – make sure people are prepared – emphasize this pain is scrum working not the opposite – was this problem there before, and will fixing it make things better – never had a team that said Scrum created a problem – be ready to go on a rescue mission – sometimes teams need help, can't always solve things on their own – what kind of help? - more facilitative help but can include direct suggestions – teams need to build their muscles
8.get experienced help – mechanics simple, but still help is useful – but outside perspective can be very positive calm reassurance – fear of looking like an “ass” and being the “Scrum guy” as a leader – spot the small stuff that can be very telling – comes with experience
9.your enemy is your friend – spend the most time with the people who like scrum the least – the detractors can have much more impact in early stages – make them informally part of the team – take their problems and ask them to help fix them – some of them might have some good points – figure it out early – don't let battle lines get drawn
10.be prepared to use guerrilla tactics to get things done – some policy/strategy stuff – but many are just little bumps in the road – e.g. Conference room assigned but had a big conference table so couldn't stand up – tried to get table moved by facilities – got email “thanks for getting table moved out” - table disappeared one weekend – someone came in and tipped over table and moved it out – don't know where it went
11.make good information more accessible than bad information – rumor mill will go into overdrive – email updates, brownbags, top 20 myths, FAQ – continuous flow of good info
12.find your evangelists – build a network of scrum proponents in every group and level of the organization – knowledge of reality both good and bad – able to speak with candor – including bad news – anchor since day one – if scrum is as good as it needs to be, it doesn't really need me to defend it – individuals using it should inform the organization about the reality
1.Senior executives – need to have an advocate but have to be careful with it – with a single statement that person can set the tone – danger in getting exec too excited – can lead to top down imposition
1.Story about “Let's Go” travel guides – every student reporter is fired every year – publisher has no power because temp work – used very scrum-like process
2.Something connected to a prior experience
13.Make the result visible – distributed results of survey to the rest of the team – this is the good, this is the bad – made people feel comfortable to enter the conversation – this is Scrum fixing itself
14.The urge to tinker is great – everyone has a way to improve scrum – some are necessary adaptations – a lot of them aren't – e.g. We're going to split out the eng, design and qa sprints (subtle reversion to waterfall), want SM and PO to be same person, want to use some practices – say “That's fine” but reflect and compare – make very clear what is and what is not Scrum – say “using agile practices” - don't let Scrum's name get sullied by experiments that aren't scrum – but experiments are still okay
15.Scrum will always be messy – Scrum is not about cleanliness, its about reality – people are insensitive and inconsistent – make mistakes and bad choices – Scrum makes the mess visible – if it feels too clean it may not be working – even the final product is messy – there is no utopia we will arrive at
Biggest problem:
first question: what does it stand for? What is the acronym
propose making it an acronym
Mad About You – Society for the Complete Ruination of Universal Mankind
Screwing Customers Royally with Methodology

How did Yahoo! get bamboozled by waterfall?
Accenture as experts in a time of trouble

Mike Cohn Filling your Backlog with User Stories

Tim Dorsey Wildcard Systems from Florida

SVP of performance improvement @ Wildcard
6 sigma and Lean
Brian Stallings from Citibank IT

change is often compared to a step into the dark
took four weeks to see results were much better – CEO took whole org to scrum immediately
What is the light at the end of the tunnel? Train? End of tunnel?
You need a leadership that will be the light
Vital stats
founded in 1997
move from cash to electronic payments – whitebox of gift cards
prepaid payment card services
2004 revenues 57mil 40-50% growth per yearsglobal

2000 – 700 million in transactions
2004 – 3.45 billion in transactions – 6 second response time

Now have 50 clients

12 million cards issued

Flexible Solutions – Managed for Client Success

Want to do good – but kept tripping over selves

System was a catastrophe waiting to happen – growth faster than expected

No fallback position because of growth

9 months scrumming last july 27 dev 6 qa 160 dev 60 qa now

Client feedback and employee morale – before scrum – not friendly to deal with, products always late, lots of bugs (but still best in business) – 82% of employees said they didn't like coming to work – tonnes of overtime, multiple projects

Speaking executive language is very important to going enterprise wide

Executive support – let go SVP of Sales cause he couldn't get with the program

Scrum:
1.process
2.technology
3.scrum teams (operational) everyone using it
4.people
5.org and infrastructure
6.client involvement
7.culture, behavior, morale
8.competitive advantage

Enterprise -wide implementation of Scrum:
1.Strategic Alignment
2.Organizational development – team building
3.Organizational analysis – metrics what is really going on?
4.Implement for Results
1.Symptom -> leap of faith -> solution

Took a baseline

Strategic Alignment (setting the course)
vision values and mission
process boundaries and accountability
goals indicators and targets
participation, buy-in and ownership
communications: structure and process
Lessos learned:
+strong executive support and review
+professional coaching and guidance
+consistent scrum practices
-WCS Culture: “get it done no matter what”
-recreate what we just threw out
-good is the enemy of great

Organizational Development (preparing the people)
team building and dynamics
roster roles and ground rules
expectations and concerns
interpersonal skills and meeting effectiveness
communications: metrics and alignment
Lessons Learned:
+strong review process
+learning organization (releases) – raising the bar means controlled release of the process improvements
+time boxed meetings
+team selection (teams initially had a team lead with 6months, a totally new scrummaster and 4 contractors)
-PO wanted to “own” the team
-lack of shared accountability (lack of collective knowledge of state of tasks)
-we're different, “our client expects...” - clients are exposed to “dirty laundry” through the daily scrum as chickens and they love it

Organizational Analysis (looking in the mirror)
selection criteria & ROI
process and tools
clients, suppliers, products and services
resources and portfolio management
communications: available and consistent – e.g. Mandate on use of Primavera for communication
Lessons Learned:
+Utilized Primavera for Scrum Template
+Staffing Models Reflect Backlogs
+financial benefits – able to move from $150/hr for dev to $60/hr only ask 2 weeks notice to shut team down
+client involvement
- ROI responsibility
-poor forecasting of Start and Due Dates
-valuable early weeks wasted waiting for client decisions

Implementing for Results (making it happen)
scrum planning and launch (2 weeks)
product backlog and estimates
sprint planning decomposition and review
agile programming tools
communications: daily scrum meetings and burndown charts
Lessons Learned
+introduced launch checklist
+consistent backlog and decomposition format
+application code collisions
+operational bottlenecks exposed
-overall sizing estimates were poor
-didn't require burndown charts immediately
-financial impact of a scrum team

Scrum Assessment: Radar Chart

Two week sprints all ending on the same day across the organization

What happens in two week ramp up after team formation develop backlog, interview clients, interview systems people

Stick to strictly normal working hours – teams are allowed to choose to work on the weekend but if it starts being a regular occurance then look at why

Metrics:
focus on process metrics

Posted by Mishkin Berteig at 10:35 AM | |

May 11, 2005

Appropriate Metrics

At the Advanced ScrumMaster Training, Ken Schwaber presented a substantial amount of thinking about metrics used with Scrum. The main driver for thinking about metrics has come from implementing Scrum in enterprise situations. Management expects metrics to be used in order to provide visibility into the progress of the Scrum implementation.

While this driver has some legitimacy, there are three main concerns to prescribing metrics for use with Scrum.

1. Planned/Engineering Approach - metrics such as "ideal person days" smell like the bad old way of treating people as resources that can be swapped in and out of a project.

2. Normative vs. Empirical - metrics are often used to set a standard for reasons such as prediction, and expectation. Scrum is about discovery and improvement not prediction and planning.

3. Is Something in Scrum not Working? Is adoption being hindered? Are too many Scrum implementations failing? Are metrics a critical success factor?

Keep these concerns in mind while considerig the uses of metrics.

What are Metrics for?

1. Self-Evaluation over Time - use a metric to track the progress of a group. A measurement is taken at a certain point in time, and then taken repeatedly over intervals. Example: the velocity at which a team completes work can be used to identify problems and opportunities for a team.

2. Control - use a metric to legislate the qualities of some process or attribute of work. A goal or standard is set for a measurement. The size of a queue of projects waiting to be worked upon by a team can be controlled in order to limit the size of work in progress and therefore project inventory.

3. Prediction - use a metric with values collected over time in order to predict future values of that metric. By implication, the metric is used to predict the performance of a system. The number of additional tasks discovered inside an iteration can be tracked and used to determine future expectations on extra tasks discovered.

4. Performance Measurement - use a metric in order to determine rewards and/or punishments and/or adjustments to behavior. An individual on a team may be evaluated based on their productivity as measured by lines of code completed and rewarded or penalized on that basis (not recommended!).

5. Behavior Motivation - use a metric to guide behavior by setting a context for thinking, action and reflection. Focus on an important measure in order to draw attention to improving the attribute with which the metric is associated. Measuring the time elapsed from conception of a project idea to the time it actually delivers valuable results can draw attention to improving speed.

The Lesson from Good to Great

Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins discusses the attributes and behavior that are common and unique to companies that have gone from a long history of mediocre results to a long run of great results. One identified aspect is referred to as the "Hedgehog Principle". In this principle, three questions are answered: "what can we be the best in the world at?", "what can we be passionate about?", "what is my one economic driver?"

The economic driver is a metric. For example, at Walgreens, their driver is profit per customer visit. Other large institutions have other metrics. But all good to great companies have a single economic driver metric that guides all their decision making.

May 05, 2005

Change is Natural - "Embrace Change"

Kent Beck's book "Extreme Programming Explained : Embrace Change" provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all agile work. (By the way, the book is excellent.)

Change really does occur everywhere. Change is constant. A google search for "embrace change" or "change is constant" will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it.

Nevertheless, it is sometimes difficult to accomodate change when we also have a legitimate and deep desire to know what is coming next.

For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people's personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal.

Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability.

Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be “wishy-washy”, uncertain, indecisive, uncommitted or even rebellious.

The terms “agility” or “agile work” refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of agile work disciplines and practices.

Posted by Mishkin Berteig at 06:57 PM | |

April 30, 2005

Pair Programming in Software Development

<br /> Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice.

Let me start by saying that I've done pair programming on software development teams and it has worked really well for me. I freely admit that it doesn't work for everyone or in every situation however when it does work, it is the most effective form of peer review that I've ever used.

Laurie Williams of North Carolina State University has done extensive research into pair programming and has published her findings at PairProgramming.com. She has also written the book Pair Programming Illuminated with Robert Kessler. If you are interested in seeing actual research into this practice then I'd strongly recommend reading Laurie's work.

Lets look at why this practice is so controversial.

The benefits of pair programming are significant. Overall development time is reduced and quality is higher. Additionally, teams doing pair programming tend to have more fun than teams working individually. People who have done pair programming when it worked well are strong advocates for the practice as they've seen first hand what is possible.

The biggest downside to pair programming is that it can push people well outside their comfort zones. I have often heard comments like "if they make me pair, I'll quit". This is an understandable fear reaction to something that is outside our comfort zone. Pair programming cannot be effectively mandated for exactly this reason. If the team is reacting out of fear then you won't get any of the benefits of the pairing.

Another downside to pair programming that doesn't get discussed as often is that it is tiring work. After a day of pairing, the team is usually exhausted.

I've also seen problems where there is a personality clash between programmers. I coached one team where I had two otherwise excellent programmers who couldn't be paired with each other because of a personality clash. Either one could pair with anyone else on the team but they couldn't be put together.

One common myth about pair programming is that it will take twice as long to complete a certain amount of functionality. In my experience (and the research backs this up), a pair will take longer to write the initial code but will spend less time debugging as the code will have significantly fewer defects. When the total developer time is measured, it actually turns out that pairs are more effective than individuals.

To be perfectly honest, I didn't believe this claim myself until I actually tried it. Now I've seen the results first hand.

One nice side effect of pairing is that you are continually cross training the team. Over time, everyone will learn all parts of the application and therefore the team will be less susceptible to staffing changes.

If your team is open to the idea of pair programming then you can get some significant benefits from this practice. Be aware however, that mandating the use of pair programming can be disastrous if the team is not receptive.

Posted by Michael Bowler at 03:28 PM | | | TrackBack

April 19, 2005

Considering the Agile Manifesto and the Axioms of Agile Work

The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Having studied Scrum, and attempted to apply agile practices on non-software projects in non-corporate, non-new-product-development efforts, I am painfully aware that the Agile Software Manifesto needs some re-jigging to become the Agile Work Manifesto. My first cut at doing this was to remove the software implications from the above four statements of value. This resulted in the following three statements of value:

Individuals and Interactions are preferred over Processes and Tools
Moving Towards a Valued Goal is preferred over Producing Ephemera
Responding to Change is preferred over Following a Plan

I removed the part about customer collaboration because I felt that it was strongly implied by "Individuals and Interactions" and "Moving Towards a Valued Goal" and because not all efforts have identifiable customers in the sense that a business effort usually does.

Once I got to this point, I started to feel like the statements of value were not really getting to the fundamental assumptions or principles or axioms of Agile Work. I thought quite a bit about each value and what it was really saying at a very basic level. For example, "Individuals and Interactions over Processes and Tools" is partly about the value and power of human beings. What is that power? "Moving Towards a Valued Goal over Producing Ephemera" begs the questions of what is a valued goal? and can ephemera be valued? and for that matter, what exactly constitutes ephemera and its opposite? Finally, "Responding to Change over Following a Plan" is really saying that plans don't tend to work. And why is that? So in order to answer those questsions, I have come up with the following three Agile Work Axioms:

People are Creators
Perception Mediates Reality
Change is Constant

People are creators and that's why its so important for us to improve ourselves and our interactions with others. Perception mediates reality and that's why we must produce results that are perceived as valuable to those who care about our results. Change is constant and that's why following a plan never works... unless you "embrace change" (Beck). But there is still something missing. There is a foundation necessary to make these principles work together in real human environments.

Truthfulness is the Foundation of Agile Work

Posted by Mishkin Berteig at 10:32 PM | |

Agile Advice

Thoughts and experiences for practitioners of Agile Work, the Middle Way to Excellence.