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.”
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|mailchimp_landing_site||1 month||The cookie is set by MailChimp to record which page the user first visited.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_42152348_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|NID||6 months||NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|COMPASS||1 hour||No description|
|cookies.js||session||No description available.|
|S||1 hour||No description available.|
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.
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.
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?
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.
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.