Triggered by the comparison with banks, FWIW here some nostalgia (or rather lack of): I worked at a large airline for several decades, their procedures are very similar to large banks. Some pro's and con's of the old ways of doing things:
I don't think we stabbed the user twice a year with a large knife. There was a large emphasis on requirements analysis, feasibility study, design in several phases, and testing. In my database years, not only was the procedure for every database structure change scripted in detail, reviewed and tested, the same happened with the fallback procedure. No improvisation whatsoever. Changes were planned centrally and signed off by a change manager after consulting change coordinators (two of many ITIL roles) so that no collisions occurred with other changes or client peak workload periods. Needless to say this was tedious for IT people, and a major reason why we needed several thousands of them. But everybody knew it would only take just a few days (we guessed three) of major failure of say the reservation system to put us out of business. Not because of three days of missed revenue, but by loss of reputation with the general public (read: fear of flying with an airline who can't control their IT processes, even when all on board IT was delivered shrink wrapped with the planes). Did all this utmost cautious and responsible behavior make user-colleagues happy? Not so much. The flipside was that change always was slow, and even smallish feature requests cost a fortune, and large projects typically took years even in the design stage. But they worked on first release almost always, although very often with less functionality than originally envisaged (there was always a phase II, which did not always materialize). The mantra was 'there are three challenges: fixed cost, fixed time and fixed product'. Erik -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Erik Moeller Sent: Wednesday, March 05, 2014 7:12 To: A mailing list to discuss team practices in Wikimedia organizations Cc: Development and Operations Engineers Subject: Re: [Engineering] [teampractices] Feedback requested on proposal for creation of Agile Specialist Group On Tue, Mar 4, 2014 at 7:52 PM, Whatamidoing (WMF)/Sherry Snyder <[email protected]> wrote: > "Don't poke me at all", for most of them, means "do not ever release > software that contains bugs that they will personally experience". > For another subset, it means never making any UI changes. It's a > thoroughtly unrealistic position, but those are their real opinions. > > If you want to reduce "misunderstandings" by this segment of the > userbase, then you might consider re-writing your very public proposal > to identify any potental benefits to end users, e.g., by increasing > the thoroughness of QA work by relieving some people of non-technical duties. Sherry, I think the suggestion to add a "Benefits to end users" section to the proposal is an excellent one. Matt is absolutely correct that this isn't about "pushing out more things faster", it's about creating higher quality software - it simply turns out that _one_ of the ways to do that is to shorten the elapsed time between a programmer writing code and an end user executing said code, and to create the preconditions (automated testing, etc.) to make that possible. But Arthur's proposal boils down to this: Let's find ways to help all our teams continuously improve how we deliver value to our users. A program like BetaFeatures can actually slow things down in terms of the speed at which a feature is delivered to _all_ users, but increase the overall value that is delivered to users. The mobile team, which Arthur is ScrumMaster on, had an alpha->beta release cycle for mobile features well before the BetaFeatures framework for the desktop existed -- so the idea of careful, staged rollouts is in no way inconsistent with a well-run team. In fact, it often depends on it. It's important to correct caricatures that a watchword like Agile will evoke, and I agree with Ori that "Agile" isn't the only game in town and also under-represents the importance of open source developer engagement, transparency, and other aspects of how WMF teams operate. We have a team practices mailing list, so why not a Team Practices Group at WMF? That to me also paints a larger vision of the potential future of that group than simply the House of ScrumMasters, while still beginning with a modest investment focused on well-understood pain points to demonstrate the value to the org. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation _______________________________________________ Engineering mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/engineering _______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
