Friday, 31 August 2018

What is Agile Software Development from the Perspective of Product Owner?



      Agile Software Development acknowledges the importance of communication between the business and technical team. Agile is a set of values and principles. It is the collection of beliefs that teams can use to make decisions about how to do the work in developing software. The agile process is dynamic, encourage flexible and respond to the change. It forces a different way of thinking about developing and improving the product. It relies on team effort with varied level of expertise and the process can complete more efficiently and smoothly.

Empower the Right Agile Product Owner:  For every entrepreneur and startup, the challenge to the product owner is to build a compelling product design in time. Here are the crucial challenges while implementing and managing the projects.

            * Time Management

            * Short-term Vs Long Term Goals

            * Direction and Delivery of the project

            * Analysis of Customer Needs

            * Command & Control Vs Adapt & Inspect

      Agile Product Owner is responsible for maximizing the business value delivered by the team.  The ideal product owner is the person with experience, authority, and bandwidth to make all decisions regarding the features and the priority to add the product. Product Owner has the ultimate accountability of health and well being of your product. He owns the product vision and understanding customer needs and making continual decisions on what to build and when. He manages the stakeholders and sponsors expectations. Here are the things to know as an agile product owner,


1. Develop the holistic view of market segments, customer needs, and value: Agile focus on value, and delivering the highest value features as soon as possible. So, everyone from c-suite to engineering team needs to have their eyes fixed on the prize and built collaborative product visions and objectives with representatives from cross-functional disciplines.

2. Build an Empathy with your Customer: Share the experience from your customer visits and interactions with team members. It is good to bring your engineers, testers, business analyst, user experience and the members of the delivery team to the customer to observe.

3. Answer all the questions about Work in Progress: Be available for the clarification of acceptance criteria, prototypes review, completed stories and demos. Until you see it, the team can't consider it done. Always attend your team demos and market the demo.

4. Be Part of Team Retrospective Meeting: Be ready to give and receive feedback. Also, Be engaged and expect retrospective to be well facilitated, and transparent. Each retrospective should conclude with one or more specific actions for improvement.

5. Leverage Agile Strategically to shape the Product to Market Need: Capture the feedback from the customer and use it to reshape the vision, requirements, and priorities.  Delegate the decision making authority to business analyst, tester, or Scrum Master and whoever has the right skills.

6. Develop the Product inch by inch: Think small tests or slices with clearly defined desired outcomes. Teams need clear, measurable acceptance criteria so they can create tests necessary and deliver what you need.

7. Sketch out the View of Product: On the agile product, you don't try to understand or predict the product requirements up front. However, you need to sketch out the long view of the product to establish a common focus and organisational resources of people, money, space, and governance. From the tipping point, you need to define what to build in each release and each iteration.

        There are 3 levels - Product, Release, and Iteration corresponds to 3 views(Big views, Pre View and Now View) of the product. The Big view is an overall understanding of the product and the sequence of the delivery. The Preview outlines what product functionality to deliver in given release and obtain the agreement on product backlog items to deliver in the first few iterations. The Now view defines the item deliver in an iteration. So, the Product Owner should keep the big view in mind, when they progress through Pre-view and Now View.

8. Use Product Roadmap for the Guidance: Agile projects need a planning and analysis tool called product roadmap. It is an evolving plan of product releases with a brief description of themes, features, and anticipated outcomes. The product roadmap is the product vision over time and satisfies goals and objectives. There are 2 things to remember: Evolving and Over time. When the product is developed, the roadmap must be revised to include technologies, opportunities, marketing condition, customer feedback and new learning.

9. Develop KPI's and use to drive Priorities:  Product Owners need to ensure their development team is data-driven in decision making. Their role is to define key KPI's on product performance in the areas such as customer satisfaction, financial, risk and other criteria to help drive priorities.

10. Develop Brands, Platforms, and Ecosystem: Product Owners need to recognise that product do not survive in silos. They need to consider how their offering become a platform or interface into an appropriate ecosystem. They must also partner with marketing to build brands, prospects and develop the relationships. Product Owner should know how and when to thank the team for accomplishment on small and big wins.

       Product Owner has the vision and passionate about the product. He knows why we built the product, the Problem to Solve and for whom to deliver the product. These individuals maximise the value of the product and built according to Scrumguides. Stakeholders are the people to use the product, and they are affected by the system being developed. He needs and expresses ideas as user stories.

        For instance, In the Hotel Reservation System, stakeholder needs to book the hotel and can describe as one user story. The development team has to build the system. This agile team has the capacity to release user stories 4-6 per week. But, the bunch of stakeholders has the number of ideas and visions. Suppose, they ask for 10 user stories per week to develop the system. The development team gets overloaded by user stories. The product owner takes the responsibility to limit the work(ex, WIP limit =5) without causing overloading. The side effect of WIP Limit is the formation of the queue in front of the development team. It is called the product backlog.


     There is a tradeoff between different types of values. It includes short term and long term thinking. Earlier on the project, There is a need to analyse the following factors,

       * Scope - It is to define the total quantity and functionality planned to develop

       * Business Risk - It is to analyse what we are building is the right thing?

       * Technical Risk -  Which platform to work on the scale?

       * Resources - Number of people working on the projects

       * Social Risk - Can these people build on?

       * Cost & Schedule Risk - Can we finish the product at the reasonable amount of time?

The Challenges can be solved, once you have the answers to these questions,

     * What is the right thing to build?

     * How do we build up the right thing?

     * How can we do it most effectively?

     * How to coordinate with the team to do it effectively and in time?

        Designing the valuable products, ensuring priorities and productivity of the organisation is a chief role of the Product Owner. If the PO fails in channelising above roles and responsibility, the project gets doomed. So, it is essential for any product owner to recognise the process in which roles and team work together for the success of a project.

       When the uncertainty is high, it is necessary to focus on knowledge acquisition like user interface, prototypes and technical information and experiments. The product owner can decide what should be in the queue, the sequence, the value of the story and the size. The biggest value can discuss with the stakeholders. Every time the team delivers the product to real users, the team gets the idea of value and size. Product Ownership is all about the communication about the prioritisation, value, and size that are called backlog grouping.

    From the Customer Value perspective, When the uncertainty is reduced, we can focus more and more on customer value. By doing the highest stories first, you can get the steep customer value, and the value curve gradually flattens out. So, build the important stuff and add the noticed features first. At any point, the customer feels met the value, trim the tail and move on to another or whole new feature on the same product. It is called business agility. So, the value can define as,

                      Value($) =  Knowledge Value(?) + Customer Value(😊)


The Product Backlog - Ultimate To-Do List: A product backlog is a prioritised list of work for the development team that derives from the roadmap and its requirements. The important items are at the top of the product backlog. So, the team knows what to deliver first. The development team pulls the work from product backlog either continually from kanban or by the iteration scrum.

             The roadmap can be broken down into epics(here green, blue, teal) and user stories for each of those epics. The product owner organises the user stories into the single list for the development team. Product Owner Prioritize user stories based on,

 * Customer Requirement

 * Urgency of getting the feedback

 * Relative Implementation difficulty

  * Symbiotic relationship between work items (e.g. B is easier if we do A first)

Effective Product Owner seeks input and feedback to optimise everyone's workload and the product delivery.





Wednesday, 15 August 2018

How to Scale the Agile with Scaled Agile Framework(SAFe) and Large Scale Scrum(LeSS)?


 SAFe Introduction: The Scaled Agile Framework(SAFe) built upon Agile, Lean Systems Thinking and Product Development Flow. It allows agile to be scalable for enterprise systems and software. Similar to Scrum, it offers the flexible and evolving framework in which milestones are met to complete a larger project. It provides practices, roles, artifacts and activities for agile development at the enterprise scale. It is a loved resource for large enterprise companies that driven by its structural and methodical approach to project alignment and completion.
     The Scaled Agile Framework can be implemented in the enterprise-class product or service initiative. It allows the user to see the SAFe Big picture to understand the roles, teams, activities necessary in enterprises. SAFe adoption delivers the best business benefits concerning faster time to market, higher quality of the product, improves the productivity and employee engagement.

    Delivering the Software with SAFe: One of the activities of SAFe is the alignment of multiple agile teams around the value streams. It is the lean construct that provides the organisational pattern for delivering the continuous flow of value. Value Streams are realised through the Agile Release Trains(ARTs). It serves as the delivery mechanism for value streams. The key concepts of ARTs are,
    * ARTs work on a fixed and reliable schedule provides the regular development and predictable planning. They also provide an architectural and UX guidance and release governance.
     * The people needed to the ART are dedicated to the train regardless of the reporting structure. It makes easier to apply SAFe without reorganising the enterprise.

  Program Level work of Scaled Agile Framework: Program-level work accelerate the Agile Release Train(ART) that delivers the solution incrementally to the stakeholders. It consists of planning, program kanban, and adapt activities which inspect the optimum quality of the solution.
      The Agile Release Train consists of multiple agile teams, and the individuals are responsible for leading the Train and providing the maximum output in their roles as,
     * Release Train Engineer: Guides the flow of value in the Agile Release Train
     * System Architect and Product Manager: Constructs the architecture of the System. The System Architect has design authority at the program level.
     * Product Manager: Product Manager has the complete authority over the content and understands the Customer Needs
     * Business Owner: Stakeholders or Customers can provide the feedback of the product
Artifacts are the result at the program level that is,
    * Features: items that are become part of the final solutions
    * Product/Program Backlog: It is the list of features that have to be implemented for an Agile Release Train.
    * Program Epics: It originates from Portfolio Epics and become part of the Agile Release Train.
    * PI Objectives: The Program Increment Objective which has to be achieved
    * Architectural Runway: It is the technical vision consisting of code and the features that become the part of the solution that enhances the value of the business.
Portfolio Level Requirements: The collection of multiple value streams is called as a portfolio. It connects the enterprise software via themes like investment funding, program management, strategy. Each theme assists with overall budget planning in large development initiatives called epics. Business epics are the customer-facing solution while the architectural epics are technology facing solutions that are managed in the kanban system.


Configurations of SAFe: Businesses can choose the configuration of SAFe to complete the enterprise software. It can be defined as,
  * Essential SAFe: It is the basic configuration and businesses choose this configuration because it focuses on the critical elements needed to be successful. It includes a foundation with team and program levels.
  * Large Solution SAFe: This is same as essential SAFe with a large solution level added in place of Program Level. This Solution train ensures value delivery of the most complicated large-scale systems.
   * Portfolio SAFe: It contains 3 levels such as Team, Program, and Portfolio level requirements. In Portfolio level, the budgets are defined with the help of epics and themes.
   * Value Stream - There is a 4th level SAFe framework used to scale the enterprise solutions. It is an additional layer between the  Program level and Portfolio level. A value stream can be defined as the series of steps it takes to deliver value from the beginning of development to customer interaction. It flows from customer request to delivery.
  * Full SAFe: It is the configuration that has all the configurations of SAFe in one package. It is a very large systems contain thousands of people to develop. It comprises Team, Project, Portfolio and Large Solutions.

Here is the nutshell of SAFe,
                                   Image Credit: Henrik Kniberg

Adoption of SAFe: The Value Stream that produces the consistent result is essential to the adoption of SAFe to the Organization. So, consider these question to identify the value stream,
       * Is the Executive Supports this idea?
       * Where are the team members are located and distributed?
       * What are the programs that provide the biggest opportunity?
       * What program to adopt SAFe the fastest?
   If you are looking for a solution to scale your development platform for large-scale enterprise solutions, SAFe could be the right iteration of Agile for your business. The benefits of using SAFe in your enterprise solution includes the organised structure, clear definitions and boundaries with the flexibility and overall ability to scale with program needs. SAFe based on the principles of Agile for developers who are used in scrum and sprints to provide consistent results with the same level of reliability. It makes an excellent choice for developers in any organisation that needs to restructure their development framework and processes.

 Large Scale Scrum(LeSS) Introduction:  Is it possible the small-scale development can apply the large-scale development? This question has driven Craig Larman and BassVodde to hundreds of experiments and formulate the LeSS. LeSS scales up the activities in the scrum, applying at the team-of-teams level, while the scrum is single team oriented. Large Scale planning is done by delegating one or two members from each team to the higher level team.  Retrospective and scrum of scrum problem solving are done in the same way. LeSS is defined by minimalism and minimal process, i.e. use as little process as possible to get multiple teams to work well.  LeSS is a solution of how Scrum is intended to work.

Overview: LeSS has a set of principles and experiments. It is based on some of the proven principles of Queueing Theory, System Thinking, Empirical Process Control. It is a product development framework for building the products with at least 2 teams. It is based on the scrum rules, and it can extend multiple team scrum. LeSS tries to stay true to the Agile Manifesto and scrum while figuring out how to work with more teams on the same product.
      Also, LeSS manage the products as products and not as projects. It leads to permanent long lived team owning their work and continuously improving forever. The effect of having the lot of roles, artifacts, process, and layers causes the team does not own the process, the process own the team. With LeSS, you have less roles, less artifacts, and less process but more ownership, creativity, improvement and purpose. It is called More with LeSS.


LeSS Framework: It is a Scrum with Scrum master, development team and product owner. This stable team grows into Feature team. LeSS is based on lean thinking and systems thinking. LeSS organisations follow a simple structure. Work is organised around the teams, and mismatch of skills triggers the learning and coordination within existing teams. Feature teams scales the team that goes above 8 members, and then the additional structure is needed. The requirement area provides this structure with concepts behind the feature teams. Requirement area is the categorisation of the requirement, leading to different views of the Product Backlog managed by a Product Owner. LeSS has an architecture and design, technical excellence, and continuous integration to add value to scrum. It looks like the below picture,


Organizational Descaling & Adoption: When adopting to LeSS, it will reflect the structure of your organisation. The organisational problems that are traditionally solving in a complex way can be solved more easily in LeSS. The small batches of working software Sprint by Sprint enables the removal of complexity in traditional development.
    Traditionally, Organizations manage the work using the projects. A project from Agile is managing the large batch of requirements towards the release. The project way of managing the work is obsolete when focusing on the product and delivering value to the customer. It is much easier to manage small batches of work via product backlog for the life of product. This allows investing within budget in the product, based on the predicted and realised customer value. Thus LeSS organisation descaled the organisation by removing projects and project management and solve the organisational problem of managing the work.

Business Analysis Are the Focal Point For Scaling Agile: Most of the organisations are delighted with the results produced on the agile projects, but they are struggling in the application on large and complex projects and adaptation in enterprise-wide frameworks like Scrum of Scrums, Scaled Agile Framework(SAFe), Large Scale Scrum(LeSS) and Nexus. There is a great deal about which framework is best that there is a need for coordination, integration, and communication among agile teams related to the solution being developed. It is a Business Analysis work that has always been needed on large, integrated projects - the coordination of dependencies, security, business and technical impacts, and version control etc.,