Scaling Scrum

Worth reading on Scaling Scrum from the founders….

Ken Schwaber's Blog: Telling It Like It Is

Jeff Sutherland and I have helped hundreds of organizations scale their projects, enable their entire product development, and thread Scrum through their organizations. For sure, none of them were easy, and each had its own unique challenges. Each had its own structure, culture, goals and strategies, challenges, current practices and infrastructure, domains of competence, existing software, and people.

We assert that only a systematic, emergent, managed initiative to scale succeeds. Every initiative to scale is unique. Nobody knows what your organization needs to scale Scrum. And, nobody knows what your organization will look like as you scale.

To get a good feel for what scaling Scrum feels like, I refer you to Eliyahu Goldratt’s “The Goal” (or any of his later books), or Gene Kim and Kevin Behr’s “The Phoenix Project.” You will see the difficulty of teasing through symptoms to root causes, the effort to find solutions, and the…

View original post 374 more words

Another one on calculating an Initial Velocity

This is adapted from http://bit.ly/1o8yysf

Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the features successfully delivered in the last sprint or iteration. What about the initial iteration?

Terms to understand when calculating initial velocity:

[1] Number of Developers – How many developers will you have doing actual work?

[2] Capacity – What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?

[3] Number of Iteration Days – How many work days are in the iteration?

[4] Load (Capacity) Factor – The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period. e.g. 1/3 = 2.4 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours

[5] Velocity – How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc. As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 2.1 ideal developers are available. Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days. These ideal work days will be applied against your estimated features, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Happy Scruming….

Cheers

Initial Velocity

There are occasions when one needs to predict team velocity when there is no historical data available. Here is a good example of how we can establish an initial velocity. This has been adapted from Crisps Blog pages.

“This is how you can get started. Take a well known task/story as your standardised benchmark. If this a rather small story, set it to two story points so you have room for smaller stories. Estimate the rest of the stories relative to this.

Before our first planning meeting we need to know our velocity so we know how much we can commit to. But we don’t have that since we don’t have a history.

To get an initial velocity for our first sprint, we estimate the selected standard story in ideal man days. Let’s say the story is 2 story points and 4 ideal man days, we then know the team can handle 1/2 story point per ideal man day. Use the focus factor to convert ideal man day to calendar days. The focus factor is typically between 50% and 70% depending on the amount of support and interruptions. If the focus factor is 50% we can handle 1/4 story point in a calendar day (1/2 * 50%). If the team consist of five people and the sprint is 14 days we have 70 calendar man days in the sprint. 70 * 1/4 gives that we should be able to bring 17 story points into the sprint. Finally we have our initial velocity.”

Hope you liked it.

Cheers!!! Happy Scrumming.

Adaptive Leadership

December 12, 2013 Leave a comment

What is Adaptive Leadership? Today we talk a lot about Agile, the buzz around it, and how it is helping organizations transform. It is Agile that introduced the term Servant Leader, right? In the context of leadership, these terms are used interchangeably. Lets look at Adaptive Leadership.

1. Adaptive leadership is the practice of mobilizing people to tackle touch challenges and thrive.

2. Adaptive leadership is specially about change that enables the capacity to thrive.

3. Successful adaptive changes build on the past rather than jettison it.

4. Organizational adaptation occurs through experimentation.

5. Adaptation relies on diversity.

6. New adaptation significantly displace, reregulate and rearrange some old DNA.

7. Adaption takes time.

Good leaders should distinguish between technical problems and adaptive challenges. Adaptive challenges can only be addressed through changes in people’s priorities, beliefs, habits, and loyalties. Technical problems can be solved through the application of authoritative expertise and through the organization’s current structure, procedures and ways of doing things.

The adaptive leadership process consists of 3 steps, Observe, Interpret and Intervene. One must be willing to experiment and willing to take smart risks. The adaptive leader shall also engage above (intellectual, emotional, spiritual and physical) the next, and below the neck (mind, heart and body).

Finally the adaptive leader is connected to purpose, choosing among competing, legitimate purposes, sacrificing many in the service of one or a few, in doing so making a statement about what you are willing to die for, and therefore what you are willing to live for.

Have a great day.

Visit me at http://www.xicoraconsultants.com (or) http://www.vasanthanphilip.com

Vasanth

 

 

 

 

Envisioning the Product

September 26, 2013 Leave a comment

Hello,

Recently I was reading a chapter in a book. The title was “Envisioning the Product”.  It’s important that Scrum Team members know and understand what they are working for. I will mention a few snippets from the chapter.

1. The Product Vision: Understand the product vision. The vision describes why the project is being undertaken, and what the desired end state is. Asking question like, “Who is going to buy the product?”, “Who is the target customer?”, “Who are the target user?”, and so on will help pen down a vision.

2. Minimal Marketable Product: To create a vision, the Scrum team has to peek into the future and state what it believes the future product will roughly look like and do. As our ability to predict the future is limited, our best chance of success is to envision the minimal marketable product, a product with minimum functionality that meets the selected customer needs. The key is identifying a narrow set of customer needs, and full-filling them. Read the book “Software by Numbers” by Mark Denne and Jane Cleland-Huang’s for more insights.

Once the vision is available, it is turned into a shippable product by leveraging customer and user feedback; the feedback is collected by demoing product increments in the sprint review meetings and by releasing software early and frequently. Working this way allows the Scrum team to find out quickly if the right product is being developed.

Keep the following in mind.

a. Simplicity – Simplicity facilitates creating a product with the minimum functionality that is easy to use. Don’t mistake simplicity for creating simplistic products. As Leonardo da Vinci said, “Simplicity is the ultimate sophistication.”

b. Ockham’s Razor – Using simplicity as a guiding principle. Ockham said “given a choice between functionally equivalent designs, the simplest design should be selected”. Simplicity is not only about the aesthetics of a product. It means focusing on the product’s essence, building only what is really needed, and being able to adjust and extend the product easily.

c. Less is More – “The simplest way to achieve simplicity is through thoughtful reduction. When in doubt, just remove”, says MIT profession John Maeda, who is an expert in Simplicity. A company called 37Signals says “Do less than your competitors to beat them … Take whatever you think your product should be and cut it in half … Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you’ve built.”

d. Simple User Interfaces – Google says “Our hope is to evolve products in new directions instead of just adding more features.” Google doesn’t set out to create feature-rich products; our best designs include only the features that people need to accomplish their goals”.

3. Customer Needs and Product Attributes – These are at the heart of the vision and deserve close attention. Selecting the relevant customer needs tells us which market or market segment we are going to address. By focusing on the needs, we view the product as a means to an end—serving the customer or user. Product attributes, on the other hand, are the critical properties the product must have in order to meet these needs. Once we have identified the product attributes, it’s often useful to prioritize them; attributes serving several needs are important and should be high priority. Prioritization is particularly helpful when attributes conflict.

Techniques for Creating the Vision:

a. Prototypes and Mock-ups

b. Personas and Scenarios

c. Use cases and User Stories

d. Sequences and Storyboards

e. Vision boxes and Trade Journal reviews

f. Kano Model

Product Road-map – The new product versions still need goals. A product road map allows the Scrum team to capture the goals of upcoming product versions; visioning now forms a part of creating and updating the product road map. A product road map is a planning artifact that shows how the product is likely to evolve across product versions, facilitating a dialogue between the Scrum team and the stakeholders. A road map allows organizations to coordinate the development and launch of related products, for instance, a product line or a product portfolio.

Minimal Products and Product Variants – As a product matures, it might address a growing number of customer needs, for instance, by serving customers in different segments and different regions. Dealing with many diverse needs makes it more difficult to create product updates with minimum functionality; more and more features are required to support an ever-growing number of customers and users. To solve the problem, we take advantage of product variants. Each variant addresses a specific customer group and market segment.

Common mistakes to avoid:

a. No Vision

b. Prophecy Vision

c. Analysis Paralysis

d. “We know best what is good for our customers”

e. “Big is beautiful”.

Reflection: Ensure Scrum teams have a shared vision. Think big, but start small.  Put the vision to the test by inviting customers and users to sprint review meetings and by quickly releasing a product increment. Then evolve your product based on their feedback.

Hope this article has provided some perspectives on Product Development.

Have a great day.

Visit my website at www.vasanthanphilip.com

Cheers

Vasanth

 

 

 

HR’s Role in Agile Transformation

In many of my training programs, I am usually asked about the Role of HR when it comes to performance evaluation of Agile Team members. I recently found an interesting read that I thought I’ll share with you. 

Check this article out, as it provides some insights.

 http://www.scrumalliance.org/articles/468-the-importance-of-hr-in-agile-adoption

We know that the Agile Project Manager’s role is important here. The Agile PM needs to motivate teams rather than individuals. He or she also need to change the Performance measurement criteria so that it compliments rather than contradict Agile values. For this to happen the Agile Project Manager shall need to trust and empower the teams’s self organization and also work with the team to determine metrics for team evaluation. The focus should always be on team rewards rather than individual rewards.

Have a great day.

Vasanth

Agile Coaching

August 5, 2012 1 comment

Often I get questions about what Agile Coaching is all about. How is it different from being a Scrum Master or an Agile Project Manager, or for that matter, even a Agile Consultant.

An Agile Coach plays a significant role in the success of projects. Usually it is a matter of how much time a coach can spend with the team into making it a high-performing one. With delivery commitments that the teams have, it is a fine balance the coach will need to seek in an attempt to change team behaviors and practices.

An important aspect of coaching is observation. The coach needs to observe how the team is collaborating and communicating as these are two important aspects of getting things done in Agile project. Collaboration in Distributed teams is often a challenge and the Coach plays a vital role in helping teams collaborate better.

The other aspect of coaching is to provide constant feedback. The coach will observe how daily-standup’s happen, how the sprint planning/review happen, keenly observing these meetings and will provide valuable feedback on what improvements can be made to make these ceremonies effective. The feedback will be on individual as well as team level. What transpires as an outcome of this feedback is mentoring.

People who resist change are the one’s who require mentoring. The coach has to make this happen without rubbing the egos of individual who require mentoring. He/she will need to identify areas that need mentoring, and must schedule one-to-one mentoring sessions in improving those outcomes.

The other aspect of coaching is training Scrum Master or Agile Project Manager to transition into the role of Agile Coaches. Here the skills, behavior, problem handling & conflict resolution abilities of the Agile coach is to be observed to improve their own qualities that will make them as Agile coaches in future. So, as a coach you are being modeled.

Other expectations include teaching the teams in applying specific agile software engineering practices such as Test Driven Development (TDD), Refactoring, Pair Programming, etc., These practices help the teams be more productive over a period of time.

All said and done, if the teams have not shown measurable improvements in the course of your coaching journey, you may need to ask the question, “Where did I go wrong”.

I found this resource useful. Visit AgileCoachNet

You may also take a look at my website vasanthanphilipdotcom

Will keep you posted…

Cheers