Skip to main content

Scrum is Awesome! Agile is Awesome! Awesome! Awesome!

Last spring, I coached a company that wanted to get started with Scrum. I had trained a team on Scrum and accompanied them through the first few sprints. The team itself was very keen on implementing XP engineering practices, something which management did not support. My mandate ended before the project did, and so the question is, how did they do?

A big conflict between the developers and the project leader (who officially wore the ScrumMaster title, but who also had a fixed price project to deliver on time and budget) was how much effort to invest in automated testing. The customer was the P-O, so he thought quality was a great idea. The project leader wasn't so sure, he saw testing as an impediment to velocity. The team insisted, and as my mandate ended, they still had conflict on this subject.

Yesterday, I caught up with one of the developers. "How did it go?" I asked. "Scrum is awesome! Awesome! Just Awesome" he replied, repeating himself several times. (Well, the word he used was "geil," which you can translate as you see fit). So I asked "why?" His story:
Last week, I was at a trade fair to demo our product. We had just finished a sprint, so I installed the product from source based on the last build. It took 3 hours, but there were no errors. We demoed the product for three days without finding a single bug. Our PL was also demoing another product built with our traditional methods and he found bug after bug. Vindication! 
Could you have done it without Scrum? "No way!" was his answer. "Management and the customer expected to see a release every two weeks. The team had authority over engineering practices. Without that combination, our XP practices could never have taken root."


senfo said…
In a traditional agile project, it is my understanding that there is no extensive requirements-gathering stage at the beginning of a project. Instead, requirements are gathered at the beginning of each sprint. While I am a firm believer in showing frequent progress, I find it difficult to believe that anybody could successfully and/or properly architect a large-scale software project without first being able to see the big picture.

In your experience, how have you dealt with this issue?
Robert Dempsey said…
@senfo: this is a common misconception with Agile. There is a requirements gathering process up front, and even up front estimation using story points. If you don't know what you want to build in the first place, there's no way in hell your going to make any progress. With requirements, we don't get enormously in depth up front.

Typically we'll do a story carding process that starts with the who and what of the application. Then we define initial acceptance criteria. From that we can get a ballpark estimate. All of this comes from an initial vision statement of the product and the goal of what will be produced.

That scratches the surface of what agile is all about, but it'll get you going down the right road.
Unknown said…
I think a key point is to call them Features, not Requirements.

Just by calling the artifacts you collect from a customer "Requirements" you are setting yourself up for a fixed scope and the customer expectation that what you collect will be delivered.

By calling them Features the customer is free to request away.

In my opinion, a true agile process accepts Features whenever the customer feels like it.

It is up to the customer and you to collaboratively prioritize Features for a certain sprint/iteration/time-frame.

Peter said…
Hi gustin,

Good point about managing expectations.

Not sure I agree whether requirements are just features though. I guess calling a nice to have feature a requirement is a bit of a misnomer. On the other hand, we should develop what is necessary ("required"), but no more.

Unknown said…
That is true Peter, I think that is where prioritization is important.

If a feature is high priority or risky it should be done first to ensure it is in the next public release.
senfo said…
@Robert Dempsey, thank you for the clear explanation.
senfo said…
What is your take on technical staff involvement during the requirement gathering and planning stages of a project? In other words, when should technical staff be introduced to the project?
Peter said…
Hi senfo,

I ran a retrospective at a SW development house with a representative cross section of the entire company. The developers found that sales made estimates and bids without involving the dev staff. Sales found that dev was always too busy to give him an estimate.

Potential improvement: involve the team as early as possible. Evaluating an RFP to produce an estimate (and user stories if necessary) can be built into the sprint process.

Robert Dempsey said…
I greatly agree with Peter's last comment. If sales is out there making promises without the correct information and leaving it to dev to make up there's going to be major conflicts. Involving Dev as early as possible, if not doing the estimates up front, is a necessity. The onus is also on the dev team to give realistic expectations to sales.
Unknown said…
Totally agree, at the least have a representative from the technical team sit in to relate what client services or the business folks are promising and get feedback from the folks actually doing the work.

I used to be the "Director of Enterprise Architecture" at a large firm, my biggest move was filtering promises from client services. Their promises were never based in reality.
Unknown said…
hey the sales reply was from me :-)

I was logged into a different gmail account.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…