Becoming a Certified Scrum Practioner
26-09-2009Formation Scrum en français
10-10-2009Last 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.”
11 Comments
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?
@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.
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.
~)o
gustin
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.
Cheers,
Peter
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.
@Robert Dempsey, thank you for the clear explanation.
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?
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.
Cheers,
Peter
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.
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.
hey the sales reply was from me 🙂
I was logged into a different gmail account.
~)o
gustin