Typemock: Past, Present and Future
Eli Lopian of Typemock answers a few questions on Typemock origins and where Typemock is headed.
Tracking change and innovation in the enterprise software development community
Posted by Vikas Hazrati on Apr 21, 2008 07:31 PM
One of the first questions asked when Agile is introduced to an organization is about scaling. Tobias Mayers put his thoughts in his blog post where he suggested that organizations should not worry too much about scaling Scrum. If they have built a strong foundation with the correct set of Scrum practices then Scrum will scale on its own. Adopters tend to focus on quick solutions to complex problems without understanding the basics. People seem to focus too much on scaling right from the start; they should instead embrace the principles and practices of scrum to gain a deep understanding of the methodology first.I believe Scrum to be self-scaling. By that, I mean that Scrum contains all the elements required for handling complexity: self-organization, empiricism, prioritization and timeboxing.He suggested that, once everyone on the team understands the principles then, Scrum Masters can take a back seat and let the self organizing teams manage the scaling.
Among the guiding principles in these “traditions” are the following:He concluded by suggesting that instead of ignoring the analogy and dismissing it as non-relevant, agile teams should try to learn from the similarities. The main point is that instead of worrying about scaling upfront, adopters should take care in laying a solid foundation in terms of principles and practices of Scrum. Once that is done the self organizing Scrum teams will take care of scaling on their own.
It will easily be seen how such principles can apply to the scaling of Scrum:
- Our leaders are but trusted servants; they do not govern
- Each group should be autonomous except in matters affecting other groups or AA as a whole
- Each group has but one primary purpose — to carry its message to the alcoholic who still suffers
- Our leaders are but trusted servants; they do not govern (no change there)
- Each Team should be autonomous except in matters affecting other Teams or the organization as a whole.
- Each Team has but one primary purpose — to build an increment every iteration and deliver it to the Product Owner (who is possibly suffering!)
The Agile Business Analyst: Skills and Techniques needed for Agile
Evolutionary Design through Agile Development Podcast
Eli Lopian of Typemock answers a few questions on Typemock origins and where Typemock is headed.
Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.
From QCon 2008, Daniel Moth presents on using Visual Studio 2008 and .NET 3.5 to create compelling rich Windows applications.
Joshua Kerievsky, founder of Industrial Logic, talks about Industrial Extreme Programming which extends XP by including practices dealing with management, customers and developers.
Amazon Web Services (AWS) Evangelist Jeff Barr discusses SimpleDB, S3, EC2, SQS, cloud computing, how different Amazon services interact, origins of AWS, AWS globalization and the March AWS outage.
Cloud services have helped bring virtualization to the forefront. Its full power however, also includes other benefits such as high availability, disaster recovery, and rapid provisioning.
John Lam talks about his path to dynamic languages, some of the problems of making IronRuby run fast, and how the DLR helps with implementing languages.
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
No comments
Reply