“The best architectures, requirements, and designs emerge from self-organizing teams”, the Agile Manifesto announces. This raises a few questions: What are self-organizing teams? Why do we need them? What difference do self-organizing teams make? How can we support self-organization? Could there be any way to help this special kind of teamwork to emerge?
Surprisingly, there is relatively little material on what self-organizing teams are about and how to support them effectively. Organizational development consultant Sigi Kaltenecker and agile coach Peter Hundermark are writing a short book “Leading Self-Organising Teams” to be published by InfoQ later in 2014.
To read more on “What are self-organizing teams?” click here.
Paul Gorans (IBM Global Business Services) and Philippe Kruchten (University of British Columbia) published A Guide to Critical Success Factors in Agile Delivery. This guide discusses the values, benefits and challenges of agile and proposes critical success factors for implementing agile delivery in the federal government.
InfoQ interviewed Paul about implementing agile practices, how agile impacts acquisition and procurement, scaling agile communication and the usage of reviews in agile.
InfoQ: What made you decide to write this guide on implementing agile delivery? To whom is it targeted?
Paul: Our IBM Center for the Business of Government had heard about the success of one of our IBM Agile programs with a U.S. Federal Agency that I had helped transition to an Agile approach, and the formal implementation of my Agile Competency in IBM Global Business Services, Federal. They recommended that I write a guide to help other Agencies understand some of the Agile basics, and the critical success factors that I feel are required for Agile delivery, and address a few U.S. Federal specific aspects that we are often asked about (e.g. how do you conduct 508 testing in Agile?).
To read more of the interview click here.
In agile projects, when the cycle from ideas to production shortens from months to hours, each software development activity—including testing—is impacted. Reaching this level of agility in testing requires massive automation. But test execution is only one side of the coin. How do we design and maintain tests at the required speed and scale? Testing should start very early in the development process and be used as acceptance criteria by the project stakeholders.
Early test design, using a business domain language to write tests, is an efficient solution to support rapid iterations and helps align the team on the definition of done. These principles are the basis of acceptance test-driven development practices. Laurent Py shows you how the use of business domain languages enables test refactoring and accelerates automation.
To learn more click here.
I have been in charge of implementing Lean Software Development in a software vendor house for about 2 years. During this time I have been coaching a large team throughout the development of two successive versions (let’s call them V2 and V3) of our enterprise solution.
We have gradually implemented seven major changes in our organization that have helped our R&D department to remove waste from our software development process with encouraging results. This essay is about implementing these seven changes, the results we obtained and what we have learned during the journey, read more here.