Monthly Archives: October 2013

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