Enterprise Scrum Definition Release 1.01 released by Mike Beedle as business-oriented, scalable, general empirical management and execution framework.
Scrum of scrums can be used to scale the daily stand-up meeting when multiple teams are involved. Its purpose is to support agile teams in collaborating and coordinating their work with other teams. Several authors have shared views on scrum of scrums, with experiences of using them.
To incrementally develop and deliver products using agile software development, requirements are gathered and organized into a product backlog. A requirement technique that is used in agile software development is use cases. Some techniques to apply use cases for managing product requirements in agile are use case 2.0, slicing and laminating.
The product owner role from Scrum is used to interface between the business and development. In larger organization with complex products and many decisions that need to be made, having this role filled in by one person is often not feasible. InfoQ did an interview with Timo Punkka about the role of the product owner, lean portfolio management, and customer collaboration.
Enterprises that are adopting agile organizational-wide will at some time have to scale their agile practices. In a session at the Agile Methods in the Finance Sector and Complex Environment conference, attendees shared their experiences with scaling agile in enterprises.
The way that agile teams and organizations take decisions impacts the value that they can get from agile ways of working. To become agile, it can help to learn different decision making techniques, and pick the one which is most suitable for a situation.
The Scaled Agile Framework (SAFe), created by Dean Leffingwell, seems to be gaining momentum in our community and is touted as the equivalent of Scrum at an organizational level. It is currently supported by several vendors including Rally, Net Objectives, Valtech, and Ivar Jacobson International. However, not all in the community think SAFe is a good idea.
Back in November, Spotify released a paper titled "Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds". I recently had a chance to chat with Henrik Kniberg, one of the coaches on site there, to ask him some questions about the paper and to get an update on where they are today.
The introductory keynote at Agile 2012 in Dallas entitled Scaling Up Excellence was delivered by Bob Sutton, Professor of Management Science and Engineering at Stanford University and author of numerous business books including "Good Boss, Bad Boss" and "The No Asshole Rule".
The British Computing Society has awarded its Lovelace Medal 2012 to Grady Booch for his “innovative work in software architecture, software engineering and collaborative environments.”
Agile experts suggest a slow ramp up, thinking beyond Scrum of Scums, and using techniques like Feature teams, for scaling Agile projects. A feature team takes responsibility for one or two features at a time and works on them as a whole until they are done. Once the features are delivered, each team member signs up for the next feature by joining another feature team.
On January 4th, IBM announced it is going to acquire the cloud and SOA integration service company Green Hat. Testing is one of the main challenges when developing cloud or SOA based applications. Buying Green Hat IBM hopes to offer more productive testing approaches and other benefits for such types of large scale software systems. Green Hat will be integrated into IBM Rational Solution.
A number of commentators have been talking about the perceived dichotomy between Agile techniques and architectural thinking. This post investigates some of the tensions between Big Up Front Design (BDUF) and You Aint Gonna Need It (YAGNI) thinking and looks at how the two approaches can in fact work together in complimentary ways.
The Rational Unified Process(RUP) was developed through the 1990's as a framework for software engineering best practices. Features such as iterations, simplicity, focus on value and regular feedback were identified as being important for Asuccessful software engineering. A number of authors have built methodologies that adapt UP to different project domains. This article examines some of them.
Mike Cohn and others present their case to why you should consider structuring your teams around software "features" rather than software "components".