Effective Sprint Reviews:

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review ineffectively often leading  to sprint review taking long time, sprint review going out of focus, inconclusive in the end, teams and Product Owners not coming to conclusion.  In my experience, some of the common causes for this:

  • Definition of Done not identified properly
  • Objective acceptance criteria for non functional requirements
  • Lack of clear sprint goals
  • Involvement of Stakeholders
  • Time box or Sprint review meeting time taking long time
  • Attendance of team members

1. Definition of Done not identified properly:

Many times Scrum teams and Product Owners conduct the sprint review without clarity on when are the scrum teams done with their work. Establishing the agreement on definition is done is vital for the success of the sprint reviews. It is better teams identify the “Definition of Done (DOD)” before the sprint and have an agreement with the Product Owners.

Sample of “Definition of done”:

1. Working Software + Demo

  • Unit testing should be completed.
  • Code review should have been completed
  • Include any specific non functional requirement such Response time, No of users to be supported concurrently etc
  • No Critical defects

2. Tests:

  • Test Cases + Test Report showing successful tests.
  • Functionalities review by Product Owner

3. Documentation:

  • User Manual ( On-line Help)
  • Design(Internal Use)
  • Release Notes

2. Objective acceptance criteria for non functional requirements:

The scrum team should have clarity on what needs to be tested for user stories. This can be done effectively if the team has clarity on what are the acceptance criteria for non functional requirements the user or product owner expect to be met by the agile team. The non functional requirement should not be subjective, as far as possible. Hence team should ensure that Product Owner defines the objective non functional requirements in acceptance criteria as much as possible

Examples:

  • What is the response time for GUI screens?
  • No of users supported by the functionality?

3. Lack of clear sprint goals:

The central point of discussion is the Product Increment completed during the Sprint. A demonstration of the Product Increment is common in sprint review meeting. The sprint goal should be decided by the Scrum team as an outcome of the sprint planning exercise and the commitment has to be done by the team to the Product Owner, before the sprint. The ability to split user value into small, vertical, testable user stories is essential to agility, but it can be difficult to see the forest for the trees.

4. Involvement of Stakeholders:

The Scrum Master organizes and facilitates the Scrum meetings, including the Sprint Review. The Scrum Master ensures that all the stakeholders of the Scrum Team are invited to the Sprint Review. The list of stakeholders invited should include, most importantly, end users of the product and / or actual external customers who would buy the product. The Scrum Team presents the product increment during the demo portion of the Sprint Review. This presentation allows the stakeholders to give immediate feedback on the product increment including new functionality, quality, and desired future direction. If the stakeholders are not invited, then it is possible that important feedback will be missed and the Product Owner may create incomplete or sub-optimal Product Backlog.

5. Time box or Sprint review meeting time taking long time:

As per the core scrum the guideline for sprint reviews are Time-boxed to 1 hour per per week of Sprint length

  • (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)

Often team spends quite a long time without arriving at any conclusion. One of the mistakes done by the team and Product owner done, is thinking the sprint review as sort of user acceptance testing. Then they become very strict and too serious to validate what has been done or not done. Sprint review meeting should be treated as informal and fun. In this process there arises lot of back and forth discussion, justification etc. Whole idea of sprint review is to “Use frequent Inspect and adapt” approach, so that team takes the feedback frequently and adapt and adjust their approach to produce potentially shippable product increment.

6. Attendance of team members

The Sprint Review meeting supports the Scrum value of Openness and the principle of inspect and adapt.  This rule of Scrum also aligns with the Agile Manifesto principles “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Delivering the value to the customers is the key. Complete attendance of all Scrum team members allows for lot of openness among team members and effective communication of feedback from stakeholders reviewing the product increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. The successful delivery of the valuable software requires full commitment on the part of the whole team. Lack of attendance / participation impacts the openness and inspect and adapt will lack effectiveness.

Product Owner Role : What he does ?

In the “Scrum Guide” Ken Schwaber says about the product owner

“ The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures it is visible to everyone”

Still many organizations fail to understand fully the role of product owner. Product Owner plays important role in getting the product developed to achieve its desired benefits. He always represents Business and the work with the team to see that they deliver as per the business needs. He has to work collaboratively with the team such that they are in the right direction. Unless there is a close collaboration between the business people and development, the success of the product becomes distant possibility. This requires the involvement of the product owner throught the iteration and he frequently verifying the work of the team. It differs from the traditional role as product manager.

The common mistake is that “He provides help in creating the product backlog and managing it”. One should not think this is not the only role. There are quite important other things he does during the product life cycle. The product owner leads the development effort of the team. As per the Roman Pichler who has written quite well in his book “ Agile Product Management with Scrum”, some of his responsibilities are often in involves

  • Creating the product vision
  • Grooming the product backlog
  • Planning the release
  • Involving the customers, users and other stakeholders
  • Managing the budget
  • Preparing for the product launch
  • Attending the Scrum Meetings
  • Collaborating with the team

It is better to have single person as a product owner. This helps in ensuring the continuity across the releases, reduce hand offs and long term thinking. Depending on the context the role of product owner could vary from customer, sponsor, the product manager and the project manager etc. The product owner skills and competencies could change for web application product enhancement to health care applications involving the integration of hardware, software and other interfaces.

In Roman Pichler words, the product owner is typically a customer representative, such as product manager or marketing person. The product owner needs to have different skills for working with large Scrum project than who collaborates with one or two teams

Daily Stand ups: Why is it Important?

1

As organizations look for ways to compete in today’s global economy, they are turning to Agile practices and methodologies as a way to innovate and get ahead of the competition. In my experience, One of the practices that literally “stands out” among the crowd is the adoption of a daily stand-up meeting. Version One’s 2010 State of Agile Survey polled more than 4,700 participants from 91 different countries and found that 83 percent of respondents indicated they hold daily stand-up meetings.

The process of daily stand ups (Daily Scrum Meeting) is as follows

Goal:

  • Keep team coordinated and up-to-date with each other
  • Surface “blocks” or problems daily
  • Everyone stands in a circle, facing each other
  • Lasts 15 minutes or less.
  • Recommended:
  • Team and SM only (no others)

If any others are attending they can be observers, so that they do not take away the focus of the meeting

1. Everyone reports 3 things

  • What did I do since the last meeting
  • What will I do by the next meet
  • What are my “blocks” or problems

2. No discussion until after meeting ends

3. After the meeting, Scrum Master helps remove the blocks and help find solutions to the problems ( That means team resolves blocks or impediments)

Importance of Daily Stand ups and tips:

  1. The first principle of the Agile Manifesto states “We value individuals and interactions over processes and tools.” A healthy team is one that has a high degree of interaction and knowledge sharing. The daily stand-up promotes this principle creating a forum for everyone on the team to listen and share.
  2. This isn’t status update or reporting up to your manager. Sharing with your peers on the team and listening promotes a self-managed team culture.Get crisp and to the point. The Every day during stand-up, each team member answering the above three simple questions should be focused on what needs to be shared. The questions provide an opportunity to share progress, to set direction and focus, and to share anything blocking progress. Team members should get habituated to the discipline answering these questions rather than getting away or wasting too much time in telling too much information.
  3. Timeliness is very important. Please ensure Daily stand ups meetings go no more than 15 minutes or less. One thing I hear ore commonly is, teams get to the resolution mode of discussion and start discussing about the blocks. The daily stand ups are not meant to discuss the problems they are meant only to report the blocks. Any resolution of the blocks has to be done after the meeting ends.
  4. Teams realize the importance of making work visible; transparency improves the nature of the relationship between the team and the rest of the organization, resulting in higher levels of trust and collaboration.
  5. The Daily Scrum should be held at the same location and the same time every day, ideally in the team space in front of the team’s big visible task board. Please do not do it un official spaces like cafeteria etc. this will remove the focus and seriousness of the Daily Stand up meeting.
  6. The team has an effective ScrumMaster or leader who empowers them to make decisions and helps creating openness, trust.
  7. If your Daily Scrums aren’t working, review the rules: are you really doing a Daily Scrum? If not, why not? If you modify the basic rules of Scrum, you risk accommodating dysfunction. The basic rules are surprisingly well thought out and internally consistent. So as a first step, I would ‘do it by the book’ and see if that helps.

Read Martin Fowler’s collection of patterns for the daily stand up, which provide ideas and patterns for further improvement.

 

Agile Retrospectives: What is it?

Most of us who are aware of agile principles, the 12th principle says

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

This is nothing but continuous improvement done at short intervals of time. I consider retrospective is very important. Agile retrospectives focus on right people, collaboratively work together to identify improvements about what has been done so far. In scrum, we call it “Inspect and Adapt”. This may also be called “Kaizen” in Lean principle language. If we look at our life, even in our life we become more effective if we constantly look at our past actions and identify where we did well, what we didn’t do well and improving the areas at different stages of our lives. Aiming improvements in small steps is the key than aiming for big improvements.

In agile we use similar approach and use retrospectives to look back at the previous iteration, discuss what went well and what didn’t. It is always better to know the root of the problem and hence we may spend some time on identify root causes about why the problem/pitfalls occurred. But it is not necessary to always have to identify the root cause. We believe in simplicity and think of small improvement or experiments to try in the upcoming iteration. The ultimate aim of retrospectives is to help change the team’s way of doing (team process).

The Scaled Agile Framework by Dean Lefingwell goes even one step further by classifying the improvements areas as “Quantitative” and “ Qualitative” areas. The quantitative review gathers and reviews any metrics the team is using to measure its performance.(eg: did we meet sprint goal?). The qualitative part discusses the various team practices, and the specific challenges that presented themselves in the course of the last iteration or two.  When issues have been identified, root cause analysis is performed and potential corrective actions are discussed and recorded.

Who will participate in retrospectives?

  1. First part of the meeting, the team can take the inputs from the Product Owners and his people.
  2. Second part of the meeting where team members meet separately to discuss the improvement areas for the next sprint/iteration.

Time For Retrospectives:

As per the Agile Atlas defined by Scrum Alliance , The recommended time box for the Sprint Review is one hour per week of Sprint duration. The team should take care they don’t spend too long time, ultimately they need to take a call as they are empowered to take decisions.

Ways of capturing the feedback from the teams:

  1. Team collectively identifying at the end of iteration 1) What went well 2) What didn’t go well 3) What team wants to try in the next iteration
  2. Team Radar: The team gauge how well they are doing on a variety of measures,such as, engineering practices, team values, or other processes and rate them to a scale of 1 to 4. Then they discuss how to move to Scale 5 on the areas identified. 1 rated as low, 4 rated as high on the scale
  3. Conceptual – One word to describe the sprint
  4. SWOT Analysis- Here team identify their strengths(S), Weakness(W), Opportunity(O) and Threats(T)
  5. Fish Bone : Fishbone is a way to look at root causes. Draw a fishbone diagram and write the problem or issue at the fish’s head and Label the “bones” ofthe fish with categories.

Typical categories are as follows:

  • Methods, Machines, Materials, Staffing (formerly known as Manpower)
  • Place, Procedure, People, Policies
  • Surroundings, Suppliers, Systems, Skills

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen is a great resource.

Some tips for holding successful iteration retrospectives:

  • Keep the meeting time-boxed to 30 – 60 minutes. Remember, anyhow we do it frequently at the end of each iteration which shall not go beyond 1- 4 weeks and the goal is kept small and ensure continuous improvement steps.
  • Pick only one or two things which can be done better next time than addressing all improvement areas. We can have improvement backlog items targeted for the subsequent steps.

 

Scaling Software Agility using SAFe

SAFe™ – the Scaled Agile Framework® – is an increasingly popular and proven approach for implementing lean and agile practices at enterprise scale and defined by Dean Leffingwell, the approach uses elements of Lean thinking, Agile development techniques and concepts of Product Development Flow. After several field experiences at Enterprise Scale in many organisations, SAFe has evolved into a broad and detail framework of guidance and it can be accessed at www.scaledagileframework.com

Product development at enterprises involves multiple teams, synchronization of product vision, planning, and interdependencies to continuously deliver value to customer at sustainable pace. Multiple teams have to work together to deliver on demand from the market needs. In SAFe , this is done defining identifying portfolios to various programs (E-Commerce, CRM, and Inventory Management Streams etc). Each program may have separated multiple teams to fulfill the program back log requirements and have to deliver the product releases as and when needed.

SAFe works well and effectively adopted to 50-100 team members working on a product with multiple agile teams. It provides transformation roadmap to execute and manage portfolios, using lean thinking principles moving away from the traditional mindset of managing portfolios in enterprises. It strongly believes in having a centralized strategy and local decision making. Any enterprise should have centralized strategy at portfolio level for funding investments based on the market, business needs and localized execution at programs level. This is achieved in SAFe with multiple agile teams work separately with fixed 2 weeks iterations developing on cadence, and synchronizing at program level to deliver Potential Shippable Increments (PSIs) solutions every 8-10 weeks, continuously delivering value to the customers. Hence SAFe brings close connection between Portfolios, Programs and Teams responsible for deliveries. It brings close involvement of Senior Leadership at portfolio level(VP, SVP, CTO, CXOs etc) to release management, product management responsible for product vision, road map, release planning and then to the implementation multiple agile teams where all are synchronized and aligned to deliver solutions on demand.

Scaling agile at enterprises in SAFe consists

  1. Capable Agile teams (Team Level)
  2. Scaling to Program Level
  3. Scaling to Portfolio Level

 

  1. Capable Agile teams (Team Level):

It involves in building the capability of agile teams which are cross functional to deliver valuable, fully tested software increments every 2 weeks. Agile teams are empowered, self organizing, self managing teams with developers, testers, Scrum/Agile master, Product Owner. Teams apply Scrum project management framework and extreme programming technical practices. These Agile teams operate under Program Vision, System Architecture and UX guidance. Every agile team has a Team Backlog (Similar to Product backlog in Scrum) which is derived from Program level Objectives for iteration planning.

2. Scaling at Program Level:

In SAFe agile teams at program level define release plans, self organize and self manages for continuous delivery and they use Agile Release Trains(ART). The Agile release trains are responsible to realize the value streams and organized around value streams identified at enterprise level. The budget allocated for each Agile release trains comes from Investment Themes identified at Portfolio Level by the executives responsible for portfolio management. The team of Agile teams deliver fully tested, system level solutions every 8-10 weeks in the form Potential Shippable Increments (PSIs). Agile teams perform Release Planning (PSI Planning) in the beginning of PSI release, to make sure of development collaboration and to evaluate if they are developing on Cadence.

3. Scaling at Portfolio Level:

Scaling Agile at Program level makes uses of Lean Agile principles emphasize decentralized decision making, continuous flow (sustainable value delivery). Portfolio Vision is defined my Senior Management responsible for portfolios, it guides the Investments (Investments Themes) and Enterprise Architecture to meet customer needs and business needs. Investment themes indicate how the Portfolio allocates budgets to Release Trains. The budget for a Release train comes from Investment Themes. These Investment Themes help identifying and funding new development work. Business Strategy is guided by identifying Business Epics (derived from strategic partnerships, mergers and acquisitions or unexpected events etc, may run across multiple programs, release trains etc) and use Kanban system to monitor work in process for continuous product flow. Enterprise Architecture makes use of Architectural Epics (Technological Initiatives such as System Integration out of Merger and acquisitions, performance and Scalability etc) makes use of kanban system. At portfolio level, scaling software agility also comprised of defining agile metrics and governance model (Agile project management office)

References:

  • Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
  • Scaled Agile Framework, Dean Leffing Well, Scaledagileframework.com

 

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 Salesforce.com 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.