Scaling Agile- A Perspective:

Scaling Agile is one of the hot topics being discussed in agile community currently. Most of the IT development organizations after tasting the success of agile in individual team, are feeling the need to extend the scaling software agility at enterprise level. Business needs, market demands of these large enterprises also expect them to add business value for all business lines in an organization. Hence scaling and implementing agile practices for large enterprises is becoming very much, a necessity to extend the principles of Scrum, XP, lean etc. When it comes to the large enterprises, they will be having multiple products, product lines, multiple stake holders such as release management, system architects, end customers, product management, development teams, operation teams etc.

Models like SAFe (Scaled Agile Framework) by Leffingwell, DAD( Disciplined Agile Delivery) Model by Scott Ambler, ADM (Adaptive development Methodology) used by talk of some of the agile, lean and XP practices applied successfully in large enterprises.

After having studied these models and with my experience in teaching large organizations, I felt at broader level some of the focus areas for Scaling Agile are

  • Repeating agile successes in a team across an organization
  • Applying agile thinking to cross-product projects
  • Applying agile thinking and lean thinking to development organizations

Repeating Agile successes in a team across an Organization:

Organizations might be successful in applying agile practices in one or two teams. These teams would have applied principles of agile effectively by becoming self organized teams, owning the responsibility without depending too much on the direction from management or a supervisor or Scrum Master. The team might have had good equation, alignment by way of frequent interaction among team members, communication with Product Owners, Scrum Masters and Stakeholders which were some of the important factors to achieve success. But, achieving similar success across teams in large enterprises requires involvement, alignment and communication of many stakeholders. Hence it is very important to keep this area as one of the areas of focus, while deciding a strategy for Scaling Agile in large enterprises.

Applying Agile Thinking to Cross-Product Projects:

Applying agile thinking in multiples teams across organization becomes very much important as it is vital to replicate the success across multiple products, product lines. There cannot be one size fit for all process when it comes to several products development to achieve the business value to their respective clients or customers. Teams have to have their own effective agile process, which works for them. The Product development practices adopted for one product cannot be same for other product. Applying the spirit of agility for all cross products, projects across all streams, business line than merely doing agile becomes a one of the measures of success in scaling agility in large enterprises.

Applying Agile Thinking and Lean Thinking to Development Organizations:

In large enterprises there are bigger problems. For example complexity of many systems,   multiple competing stakeholders, cross-dependencies in terms of requirements, technical dependencies, multiple Programs and Portfolio management etc . Bringing all levels (portfolio, programs and team level) of management will be another major challenge. Hence only applying agile thinking to achieve success at enterprise level may be very difficult as the problems are bigger. Hence applying lean principles and having lean thinking mindset during the adoption of development practices while scaling software agility in large enterprises is most important. The management in these organizations have to reduce waste, minimize delays, hand-offs (the example of an handoff could be, a delay in the passing a baton from one person to another in a relay)

Al Shalloway says “Most Software Problems will exhibit themselves as a delay”.

The Goal of large enterprises is to providing Value to the Customer at sustainable pace, with shortest lead time and quality. Hence it becomes great necessity to apply lean thinking principles for development organizations along with agile thinking.

The term Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck . The book presents the traditional lean principles in a modified form, as well as a set of 22 tools and compares the tools to agile practices. The Poppendiecks’ involvement in the Agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the Agile community.

Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:

  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build integrity in
  7. See the whole

Effective Product Backlog Grooming: Some Practical Tips

I am quite sure many of us would know the necessity of product backlog grooming in agile or scrum processes. It is like, before we start cooking for the day, in the kitchen we would first wash previous day utensils, clean and keep kitchen as clean as possible. Otherwise, it becomes difficult to cook when things are left unattended and kitchen is in disorder. We don’t keep things accumulating in the kitchen for more number of days. Likewise product back log items also need to have useful items, ones having value to the customer, ones with clarity for the development team for sprint planning etc. In this blog I want to list out some of the practical tips to make the product backlog grooming exercise effective, worthwhile and we don’t waste too much time.

  1. We need to take care that product backlog is prioritized such that most important items are found at the top.
  2. High priority items are identified for the next sprint planning meeting. If need be they are decomposed, refined and split into number of smaller items.
  3. Although product owner is responsible for making sure that product back log is in good shape, it is a collaborative exercise. Items are described, prioritized, decomposed and refined by entire scrum team.
  4. As per Ken Schwaber, Scrum should allocate at least 10% of time availability for grooming activities.
  5. The product owner, ScrumMaster, and the team should engage in face-to-face conversation as far as possible (in distributed scrum/agile teams it may be done differently) rather than communicating through documents.
  6. Grooming activities can be done with weekly grooming sessions or a longer session in the form of a workshop at the end of the sprint, before starting the next sprint planning.
  7. Also sprint review meetings can also be used for grooming the product backlog items where team and stakeholders discuss the way forward. That means new or unfinished items are identified, old ones are removed.
  8. Whenever a requirement is discovered, team need to ask a question why this is necessary, what value it has to the customer. Otherwise taking all the items in the product backlog creates unmanageable wish list.
  9. Describing the product backlog items is very much necessary. They could be in the form of user stories, feature, use cases etc. Example if we are using the user story format, every user story should have name, description and acceptance criteria.
  10. Product backlog items have to be grouped into related items into “themes”, if need be. This helps us to access the information properly and also enhances clarity.

Eg: Tablet having themes such as e-mail, organizer, calendar, voice communication etc.

One of the good resources for reference is “Agile Product Management with Scrum” by Roman Pichler.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>