Archive | June, 2012

Requirements Gathering Games – Enhance your BA Arsenal

27 Jun

http://www.slideshare.net/SunilMundra/requirements-games

Advertisements

Learnings From A Decade Of Agile In Practice

27 Jun

http://www.slideshare.net/SunilMundra/learnings-from-a-decade-of-agile-in-practice

 

Agile completed 10 years of formal existence in Feb 2011, from the time the Agile Manifesto and Principles were agreed upon and signed off in Feb 2001.

In these 10 years, as Agile adoption increased gradually, learnings have happened, which were perhaps not so explicitly known when Agile was born. Some of these are as follows:

1. Agile Is An Adjective

Agile is not a noun. ‘Doing’ Agile does not yield results. ‘Being’ Agile does.

2. Agile Is Value Focused

Agile focuses on Business Value, and not Tasks. Success and Progress are measured based on delivery of Business Value, and not on Task Completion. As a result, metrics used in Agile are quite different from those used traditionally.

3. Practices Should Be Tailored To Context

Application of Agile Practices is context dependent. A ‘one size fits all’ approach does not work for Agile practices.

4. Agile Is Scalable

It was thought that Agile can succeed only with small teams. However, experience has proven that it works with reasonably large sized teams as well. Several projects successfully executed by ThoughtWorks are testimony to this fact.

5. Works In Distributed Teams

Distributed development is now a reality and it was initially thought that Agile will not work in this environment, as it hinders communication. However, Agile has proven to work in this set up as well. In fact, it is an enabler to Distributed  Development, as it helps to scale without sacrificing quality, reduces project risk through greater visibility etc.

6. Tools Are Helpful

Tools help in multiple ways:

a. They radiate information real time across locations

b. They provide visibility within the team and to the client

c. They help automate testing and build activities, whose repeatability is critical for Agility

7. Documentation Is Sometimes Necessary

It is a misconception that stories are fleshed out only to the extent that fit in the Story Card. Stories need to be detailed enough to facilitate shared understanding not only between various roles on the Agile team, but also between the team and the client.So while the high level story may be written on a card, separate documentation is necessary for detailing them.

Sometimes statutory requirements may mandate additional documentation.

8. Organization Ecosystem Needs To Change

Changes required to adopt Agile and maximize benefits from it should not be limited only to the Project team. There are many changes that need to happen at the Organization level, for the change to succeed, e.g. metrics used by management for monitoring project progress and measuring project success, Performance Appraisal Systems, Seating arrangements, Hiring policies etc.

9. Need ‘Different’ Type Of People

Agile invokes a lot of collaboration, communication and feedback. This implies that people in all roles, including the tech roles, have to be good at not only the core skills required to perform their role, but also be good at soft skills as stated above.

10. Needs Collaborative Work Culture

In Agile, the focus shifts from individuals to team, with focus on high level of interactions between people. This implies that the work culture needs to be collaborative and that of high trust. People should feel fearless enough to deliver bad news early, and this requires a different culture than what prevails under a ‘command and control’ structure.

11. Team Buy In Is Critical

Agile does not work if it is imposed. Hence, its success is limited without the team buy in. The team needs to be convinced about the benefits of Agile and needs to adapt to Agile values. As stated earlier, doing Agile does not work, Being Agile does. Imposition will cause the team to merely Do Agile.

12. Coaching Should Follow Training

Many people attend training programs, obtain certifications and believe that they can apply Agile. However, given that Agile process and practices are context sensitive, adoption of Agile will yield maximum benefits if Training/Certification is coupled with Coaching. Training in helps in bringing about shared understanding of concepts. Coaching helps to internalize them, and apply them to respective context.

 

Product Manager-Being Your Own Client

27 Jun

http://www.slideshare.net/SunilMundra/product-manager-being-your-own-client

 

Quotes

  • Most products are reborn. The initial version is almost always scrapped.
  • Creating a product is hard enough, marketing it and implementing it is a ‘totally different ballgame’.
  • As a product manager it helps to have
  1. Reflexes of a juggler (to help keep multiple balls in the air)
  2. Nose of a basset hound (to help sniff the environment)
  3. Hide of rhinoceros (to help deflect the poison darts coming your way)

Outline

  • What Is A Software Product
  • Characteristics Of A Software Product
  • What Is Software Product Management
  • Product Manager Skills
  • Is BA a Good Candidate for Product Manager
  • Key Considerations In Product Creation
  • Product Management Challenges
  • Product Management Learnings

What Is A Software Product

A single application or suite of applications built by software company to be used by multiple customers

Examples: Finacle, Oracle DB 10g, SAP ERP, MS Office etc.

Characteristics Of A Software Product

  • Used by Multiple Customers
  • IP is owned by the Creator
  • It is based on Domain Knowledge
  • It is Licensed
  • It has Versions
  • It has a Life cycle

What Is Software Product Management

  • Discipline which governs a product from its inception to the market, or customer delivery, and service, in order to generate highest possible value for the customer.
  • Software Product Management is about delivering the right products, at the right time, to the right markets.
  • The main challenge of software product management is balancing the different and frequently conflicting wishes, needs and priorities of sponsors, developers, marketers and customers.

Product Manager Skills

  • Leadership
  • Domain Knowledge
  • Passion for Customer Delight
  • Multi Tasking
  • Understanding System Architecture
  • Keeping Pace with Business Environment
  • Dealing with Variety of Stakeholders
  • Managing and Mentoring People
  • Commercial Acumen
  • Showcasing Product/Solution

IS BA Good Candidate For Product Manager

  • Leadership
  • Domain Knowledge
  • Passion for Customer Delight
  • Multi Tasking
  • Understanding System Architecture
  • Keeping Pace with Business Environment
  • Dealing with Variety of Stakeholders
  • Managing and Mentoring People
  • Commercial Acumen
  • Showcasing Product/Solution

Key Considerations In Product Creation

  • Clarity on Need Intended to Fulfill
  • Sustainability of USP
  • Extent of Competition
  • Extent of Investment
  • Financial Viability
  • Capabilities in
  1. People
  2. Process
  3. Technologies
  4. Domain
  5. Marketing

Key Product Management Challenges

  • Fulfilling Cost and ROI Expectations
  • Knowledge Management
  • Getting and Retaining the right kind of People
  • Balancing Interests of Multiple Stakeholders
  • Ensuring Product remains Up To Date

Product Management Learnings

Do’s

  • Package Features as Solutions
  • Modularize Optimally
  • Accept Mistakes & Know when to ‘Cut Your Losses’
  • Always keep Customer’s TOC in mind
Dont’s
  • Aim to ‘Make Everyone Happy’
  • ‘Chew too much’ at a time, for development
  • Base Initial Dev. on Single Client Requirements
  • Use Pricing as Primary Competitive Advantage


Doing vs. Being Agile

20 Jun

Many teams believe they are Agile because they are following the prescribed Agile practices. E.g. A team may think they are Agile because they are doing daily stand up meetings, sprint planning meetings, retrospectives etc.

 

The mistake that teams often make is that they tend to treat these practices as ‘ceremonies’, thereby focusing more on getting the ‘ceremony’ done, and not so much on doing it right so as to derive the benefit that the practice is intended to provide. Take, for instance, daily stand up meetings. A team can be said to ‘be’ Agile if they can achieve the following benefits through these meetings:

 

  • Instilling a clear sense of purpose about what needs to get done
  • Focus on efficiently moving the work forward
  • Early identification of risks and blockers
  • Team members helping each other with share obstacles

 

However, many teams think they are Agile, just because they are ‘doing; stand up meetings, even when their stand up meetings are not delivering any of these benefits, or worse, have anti patterns.

 

Doing Agile practices does not translate into being Agile, unless there is focused effort put in by all team members to derive the intended benefits from that practice. Teams need to be conscious about why they are doing a practice and should aim to keep improving the maturity level of that practice.

 

To state in other words, treating Agile as a noun is futile. Teams are Agile only when they understand that Agile is an adjective and constantly work towards it and also adopt  the Agile mindset. The mindset change is required to make the transition from just ‘doing’ Agile to ‘being’ Agile.