Agile Helpline!

Top 10 Differences Between Managers and Leaders

noreply@blogger.com (Yogesh Kumar) — Mon, 01 Apr 2013 19:29:00 +0000

This short video from @ScottWilliams provides 10 clear distinctives to help understand the difference between a manager and a leader.

Be a leader...

When you rush to to get work done

noreply@blogger.com (Yogesh Kumar) — Thu, 31 Jan 2013 20:54:00 +0000

I really like the following 2 min video. Message is simple - you get what you invest. If you push your teams to get the work done to meet timelines then work may be completed but results will be below average.

Enjoy the video!

Agile Momentum Part 1 - Dealing With Friction

noreply@blogger.com (Yogesh Kumar) — Sun, 25 Mar 2012 04:19:00 +0000

In 1930s, automobile industry introduced agile in the form of lean manufacturing. With its growing popularity, other industry segments started realizing that agile principles are not limited to any industry segment or functional group. Over the past decade, software industry has also adopted agile principles and it has become a popular product development methodology. Core of agile is to structure organizations in such a way that they can embrace change and adapt quickly to service the customers in their ever changing needs. However, taking a big bang approach to agile is not a viable option for many organizations, as most successful adoptions of agile are tailored to the strengths and limitations of the specific organization.

Like any other change, agile adoption is not welcomed right away and faces resistance. Organizations observe many types of frictions which reduces the momentum during agile implementation. These frictions absorbs energy because of the resistance at various levels. Friction is not a fundamental force but occurs because of the turbulence caused by the change. First part of the "Agile Momentum" series is focused on "Agile Friction". There are three main types of frictions which are applied to the organization, process, and technical agility. You may visit "Beware of Scrum" to get a detailed context for these types of agility.

Types of Agile Friction

Static Friction: This is the force that must be overcome before agile can be implemented in a non-agile organization e.g. friction observed before piloting first agile project.
Dynamic Friction: This is the force that must be overcome to maintain uniform agile motion e.g friction encountered when people don't see immediate results after a new agile implementation. It is important for the agile leader to constantly communicate value of "inspect and adapt". Once an organization learns to manage incremental value driven by agile process, dynamic friction starts diminishing by itself.
Political Friction: This is the force resisting agile progress because of organizational politics. A good agile leader can influence negative politics by persuasive communication in agile's favor.

Organizational Maturity and Levels of Agile Friction

In the initial phases of agile adoption, organizations experience
a greater extent of static and political friction. As agile maturity increases, focus starts shifting towards dynamic friction.

Organizational maturity and growth has an inverse relationship with agile friction. Initially, when organizations overcome static friction, they start crawling. When political friction is persuaded in agile's favor, organizations start walking. Finally, when organizations learn to inspect and adapt to overcome dynamic friction, they start running. Velocity of their success depends on the speed at which they can maintain equilibrium between dynamic friction and rate of change of their business environment.

Agile leader plays a critical role in overcoming these frictions. Apart from knowing agile concepts, it is important that the leader understands his organization well enough to overcome obstacles quickly. He needs to have patience, negotiation and persuasion skills to build and sustain the momentum. Agile is not a short term journey. It is a life-long exploration in an ever changing business environment. Hence, the captain of the ship should have a long-term vision to make agile journey a positive experience for everyone - passengers, crew, and observers i.e. customers, employees, and competition.

How to Deal with Friction:

Rule 1 - Friction is unavoidable: We should accept friction as a natural part of our life. Facing friction is not always bad e.g. without friction, it will be difficult to stay on our feet. Similarly, existence of agile friction necessitates an organization to continuously inspect and reflect.

Rule 2 - Utilize friction: Friction converts energy into heat. This heat should be channelized back for building momentum e.g. agile leaders can use disagreements to fuel creative problem solving. They should take initiative and set the tone for productive outcomes.

Rule 3 - Seek to Understand: Try to understand reasons behind the friction e.g. what's really going on? Is it about personalities, roles, goals, facts or values? What is said is often just the surface, disguising the real issue. On the other hand, don't dwell too much on what caused the friction, focus more on how to resolve it, on what to do next. Rule 4 - Set the Goals: Often, friction develops as a result of unmet expectations. Agile leaders must set expectations by defining clear goals and intended outcome. It is also their responsibility to continuously communicate effectively and avoid expectation mis-match.

Rule 5 - Recognize differing perspectives: Keep in mind that conflict may arise due to people having different perceptions. You, or the other person, see things differently. This happens most frequently when one is dealing with someone from another organization, background, or culture. It’s easy to believe that we all see things the same way and then get derailed unexpectedly.

Rule 6: Don't Give-up: Recall Newton's 1st Law of motion, which says that an object tends to remain at rest or in a state of uniform motion unless acted on by an external force. Create an agile force for your organization and push hard to build the agile momentum. Remember, winners never quit and quitters never win.

In a nutshell, when agile is implemented friction is unavoidable. With good leadership this friction can be used constructively to continuously inspect and adapt the implementation process. To overcome static friction, agile leaders can persuade the key stakeholders to understand and explore value driven from agile. Once agile starts rolling, it is powerful enough to overcome other frictions as long as an organization clearly defines key drivers for the agility and invest in agile leaders.

I am currently working on an "Agile Momentum" idea which is hard to cover in one article. I would like to share parts of this series to validate my thought process and solicit your feedback. Thanks for reading the first installment of this series. I hope you found it valuable. What is your story of building agile momentum? What kind of frictions did you encounter in your agile journey? I would love to hear your experience, hence, don't forget to share your feedback as it is greatly valued.

Suggested Reading

Beware of Scrum

noreply@blogger.com (Yogesh Kumar) — Sun, 03 Jul 2011 00:39:00 +0000

Scrum is one of the biggest process invention but it does not guarantee success. Even creators of Scrum accept that more than half of the Scrum implementation does not go well. Why is that? Scrum is critical but what is more critical than Scrum? Moving from waterfall model to Scrum is a welcoming change that makes people think in the right direction. So what is the right direction?

If a person with ongoing back pain visits the doctor then doctor certainly suggests to do exercises or yoga to make body agile enough to get rid of pains. If that person is wise like me then he starts doing exercises and pain disappears. Exercises don't cure pain overnight. It requires a regular routine. Isn't it common to see pain appear again when exercises are stopped?

In this example "routine is Scrum" and "exercises are agility". A healthy person needs routine as well as exercises. Similarly, a good projects or organizations need both Scrum as well Agility.

Let's extend our example little further and review the root cause of the pain. Main reason behind this person's pain is routine of sitting in a chair with bad posture for a long time. Similarly, root cause for failed Scrum project is routine of not practicing agility for a long time.

In a nutshell, Scrum forces people to think in the right direction i.e. agility. As you can understand, routine is important but exercises are critical. Hence, Agility is more critical than Scrum. The following video depicts relationship of Scrum and Agility in great details with an creative analogy. Here are the key learning objectives:

What makes Scrum successful?
Are you failing because you are overdoing Scrum?
When not to use Scrum?

Presentation slides are available here in the pdf format.

YouTube Verison of the Video:

Suggested Agile Reading:

Agile Strategy Manifesto

noreply@blogger.com (Yogesh Kumar) — Fri, 24 Jun 2011 04:43:00 +0000

Agile product development is growing fast with intense focus on perfecting Agile execution. However, the business strategies developed by many organizations are still non-agile. For example, Agile product development teams are pushing business owners to prioritize the product backlog to deliver the highest value features in each iteration. However, business owners are not necessarily providing prioritization based on the organization's business strategy.

A successful business strategy involves making choices throughout the value chain that are interdependent. For an organization to realize the full benefit of it’s business strategies it must develop and maintain them using an Agile approach. The following video explains Agile Strategy Manifesto. You can also watch it on youtube.

KEY CHARACTERISTICS OF AGILE STRATEGY

Agile mentality: An agile organization is a fast moving, adaptable and robust business. It is capable of rapid adaptation in response to unexpected and unpredicted changes and events, market opportunities, and customer requirements. Its mentality is founded on processes and structures that facilitate speed, adaptation and robustness and that deliver coordinated results that are capable of achieving competitive performance in a highly dynamic and unpredictable business environment.
Iterative approach (inspect and adapt): In today’s competitive world, long-term strategies cannot be taken for granted. With technological advancement, time to market is shrinking which results in continuous validation of strategies through constant customer feedback and new competitor’s innovation. All elements of strategic lifecycle need to be iterative. Strategic leaders must inspect and adapt on a continuous basis to remain competitive.
Unique value proposition: An organization’s strategy must enable it to deliver a value proposition, or a set of benefits, different from what their competitors offer. Robust strategies involve trade-offs. A company must abandon or forgo some product features, services, or activities in order to be unique at others. Such trade-offs, in the product and the value chain, are what make a company truly distinctive.
Mutually reinforcing value chains: Strategy needs to be reflected in a distinctive value chain. It also defines how all the elements of what a company does fit together. A strategy involves making choices throughout the value chain that are interdependent; all an organization’s activities must be mutually reinforcing. An organization’s product development, for example, should reinforce its approach to the IT processes, and both should leverage the way it conducts after-sales service. This not only increases competitive advantage but also makes a strategy harder to imitate. Rivals can copy one activity or product feature fairly easily, but will have much more difficulty duplicating a whole system of competing.
Continuity of direction: Continuous value delivery to the customers is a necessity and it must always be guided by an agile strategic direction. Without continuity of direction, it is difficult for companies to develop skills and assets or build strong reputations with customers.

AGILE STRATEGY MANIFESTO

Initiation - Unique value creation (usually radical innovation) through perceived usefulness or desirability
Realization – Establish brand equity through incremental adoption of perceived value
Retention- Value enhancement through iterative & adaptive value chains
Transformation – Transformation (usually incremental innovation) through re-inventing value

STRATEGY (S)-CURVE
Agile strategy manifesto can be visually represented in a strategy curve (S-curve). It depicts how a product, service, technology or business progresses and evolves over time. S-curves can be viewed on an incremental level to map product evolutions and opportunities, or on a macro scale to describe the evolution of businesses and industries.On a product, service, or technology level, S-curves are usually connected to “market adoption” since the beginning of a curve relates to the birth of a new market opportunity, while the end of the curve represents the death, or obsolescence of the product, service, or technology in the market. Usually the end of one S-curve marks the transformation to a new S-curve – the one that displaces it.

Value Initiation
Strategy is the creation of a unique and valuable position, involving a different set of activities. This unique value is customer’s perceived usefulness or desirability of a product, service, technology or business. Value is generally created by radical innovation and retained by value enhancements.

The challenge of developing or re-establishing a clear strategy is often primarily an organizational one and depends on its leadership. While nurturing innovation, the leaders must also provide the discipline to decide which industry changes and customer needs the company will respond to, while avoiding organizational distractions and maintaining the company's distinctiveness.One of the leader's jobs is to teach others in the organization about strategy to guide employees in making choices that arise because of trade-offs in their individual activities and in day-to-day decisions. Strategy renders choices about what not to do, which is as important as choices about what to do.

Value Retention
Goal of strategy execution is to minimize value evaporation and maximize value retention. Strategy creates value but some of it evaporates due to poor execution and other organizational frictions. To understand Value Evaporation, assume that the strategy is right and, therefore, value creating. Thus, if there is any loss in value due to a poor strategy, it is not a part of Value Evaporation.

A good strategy cannot prevent the evaporation of value. Think of a tropical village that is perpetually short of water. So, the villagers come up with a strategy. It involves digging a big hole in the ground to create a reservoir of water from natural rain. The strategy works. The reservoir fills up. But the villagers forgot how mercilessly hot the tropical sun can be. The reservoir did not last very long. Evaporation returned its water to the atmosphere. For the villagers, what matters is not just how much water was there in the reservoir initially, but how much is retained after evaporation.

The same is true for any organization. Its goal is to come up with a strategy that maximizes value retention by incremental and mutually reinforcing execution of value chain. Key for value retention is to inspect and adapt in small increments to utilize feedback from internal and external customers. Following diagram depicts how traditional execution differs from agile execution. In traditional execution, value is stacked and only delivered in the end. On the contrary, agile execution creates a value chain.

If agile execution is done correctly, value chains start having spiral effects as explained in the following diagram and value continuously grows in each product increment/release. With a good strategy, one V-spiral triggers a new V-spiral through the transformation process.

Value Realization
Organizations establish brand equity through incremental adoption of the perceived value. As specified in the five stages of the Rogers Model of Innovation–Decision Process, adoption process can be summarized as follows:

Knowledge (knowing what the innovation is, how it works and why it works),
Persuasion (forming a personal or professional attitude toward the innovation),
Decision (deciding to reject or adopt it on a partial basis for assessing its usefulness),
Implementation (putting it into use, experiencing problems with uncertainty about its outcomes, re-inventing it for various reasons, integrating it into ongoing practices),
Confirmation (seeking reinforcement for previous decisions, which may involve reversing this decision because of conflicting messages).

These adoption phases must be linked with execution in an effective feedback loop to deliver value as per the customer needs.

Value Transformation
An organization can outperform competition only if it can establish a difference that it can preserve. As explained in the S-curve, organizations must continue to deliver greater value to customers by transforming through incremental innovations, which is a result of tweaking existing technology to create the “next iteration” of products. Sometimes, it also involves jumping S-Curves by creating or driving disruptive innovations.In the absence of transformation, value diffusion starts happening and product adoption starts to decline.

As per Rogers model, there are 5 distinguished groups of adopters:

“Innovators” are venturesome and educated, have multiple sources of information and show greater propensity to take risks. They appreciate technology for its own sake and are motivated by the idea of being a change agent in their reference group. They are willing to tolerate initial problems that may accompany new products or services and are willing to make shift solutions to such problems.
“Early Adopters” are the social leaders, popular and educated. They are the visionaries in their market and are looking to adopt and use new technology to achieve a revolutionary breakthrough that will achieve dramatic competitive advantage in their industries. They are attracted by high-risk, high-reward projects and are not very price sensitive because they envision great gains in competitive advantage from adopting a new technology.
“Early Majority” is deliberate and have many informal social contacts. Rather than looking for revolutionary changes to gain productivity enhancements, they are motivated by evolutionary changes. Their principal is “when it is time to move, let’s move all together”. This principle defines why adoption increases so rapidly in the diffusion process and causes a landslide in demand.
“Late Majority” is skeptical, traditional and of lower socio-economic status. They are very price sensitive and require completely preassembled, bulletproof solutions. They are motivated to buy technology just to stay even with the competition and often rely on a single, trusted adviser to help them make sense of technology.
“Laggards” are technology skeptics who want it only to maintain the status quo. They tend not to believe that technology can enhance productivity and are likely to block new technology purchases.

The strategy curve starts reversing when a “late majority” adopts the product because “innovators” and “early adopters” shift to a newer innovation by the competitors. In other words, market share eventually reaches the saturation level. This process results in value diffusion. This situation can be avoided by transforming business through incremental innovation.

A CASE STUDY
Apple is a perfect example of agile strategy. It introduced value through radical innovation of iPod and continuously increased adoption by incrementally adding features to the iPod series. When market started saturating with countless mp3 players, they transformed by incrementally innovating one of their iPod to iPhone. Adoption of iPhone got a good baseline and it kept growing inspite of small decline in iPod sales. Before competition could catch up with Apple's iPhone, it transformed again by incrementally innovating iPad. Apple's continuous innovations are well supported by its incremental and adaptive execution, and a very strong value chain (vision, design, execution, delivery, and support). Many other organizations are able to copy their products but no one is able to duplicate its whole system of competing.

Related Articles

You can watch more agile educational videos at Agile TV. Here are Agile TV channels:

References

The value sphere by John A. Boquist
Innovation diffusion and innovation decision process model by Rogers
Competitive advantage: creating and sustaining superior performance by Michael E. Porter
Innovation Lifecycles by Soren Kalpen

Agility Explained - Back To The Basics

noreply@blogger.com (Yogesh Kumar) — Fri, 17 Jun 2011 23:22:00 +0000

It is easy to deviate from the goals we set. If you are on a agile journey then take a step back and try to validate if you are going on a right track. May be you are too busy in implementing a process that is not really agile. It doesn't hurt to validate. Do you know types of agility? What are agility drills? How can agility drills help you in successfully implementing strategy?

The following video provides a fresh perspective on agility and explains it with the help of real life examples. I really enjoyed making it. I hope you will find it valuable. Here are the key learning objectives:

What is agility?
Types of agility - Programmed and Random
Agility drills - preset, reaction, quickness
Where does Scrum fit in agility?

Presentation slides are available here in the PDF format.

YouTube Version of the Video:

Suggested Agile Reading

6 Levels of Agile Planning

noreply@blogger.com (Yogesh Kumar) — Fri, 17 Jun 2011 23:04:00 +0000

One of the misconception is that agile process doesn't do enough planning. In reality, Agile does lot more planning and risk mitigation than traditional processes. Agile focuses on planning very often instead of doing comprehensive and assumption based planning once. Agile Planning (a.k.a. planning onion) has 6 levels - Strategy, Portfolio, Release, Iteration, Daily, and Continuous.
The following video blog peels off each layer of planning onion to provide details of planning at each level. Here is the youtube version of this video.

You can review the details of the planning layers by clicking on the following diagram. I recommend to watch video first to get a better understanding of linkage between all layers.

Agile Planning Onion Layers

Related Articles

You can watch more agile educational videos at Agile TV. Here are Agile TV channels:

Agile - A Perfect Partner

noreply@blogger.com (Yogesh Kumar) — Fri, 17 Jun 2011 03:18:00 +0000

Over the last decade, Agile has emerged as a charming leader and a shining star. More and more teams are interested in Agile but they are not sure how to get there. Taking a big bang approach to Agile is not a viable option for most of the organizations. Most successful partnerships with Agile are tailored to the strengths and limitations of the organization. This article is aimed at providing an innovative approach for Agile partnering with real life story.

Partnership Phases
As described in the “Figure A”, Agile partnership consists of 4 phases: Explore, Commit, Transform, and Expand.

1. Explore: If a team is new to agile then the best way to test its compatibility is by getting their feet wet. New teams can pick a project and experiment using various agile ideas to get the feel of the process.

2. Commit: It is important that exploration phase does not continue endlessly. Teams should come to a conclusion whether agile will help them achieve their goals effectively or not. If yes, then the team should commit to Agile by aligning with it in true sense. You can't yield full benefits by using partial process. Commitment is the key for the successful adoption.

3. Transform: Agile is less process and more self-realization, hence, adoption is unique for each team. This process transforms good teams to hyper-productive teams. There are two key driving factors of this transformation, which will be described in detail in the next section:

Incremental Investment
Inspect & Adapt

4. Expand: If an organization has big teams, then it is important to start implementation within a small subset. Once this subset goes through the maturity, process can be rolled out to other teams.

Building Partnership - A Real Lifecycle
Let’s take a deeper look at these phases to understand key steps involved in building this partnership. Remember, Agile does not need an organization; rather an effective organization needs Agile. Hence, leaders of the organizations should initiate a relationship with Agile. “Figure B” describes how this relationship matures.

Phase 1: Explore (Getting started into a new relationship)
This phase is about getting started into a new relationship i.e. find someone attractive, fall in love, and decide if this relationship is worth pursuing as a formal engagement.

1.1) Infatuation
Reading this article signifies that you are already attracted to Agile. There could be many reasons for this attraction:

Thrill of something new, which is very popular and gaining further attention.
Customers are very demanding and your organization needs to rapidly embrace the changes.
You find it hard to become effective in a controlled environment and you like how Agile promotes self-organization.
As a software professional, it is difficult to find good jobs without Agile experience in today’s market.

Agile may look nice to you but it is important to understand if it will add value to your organization. You need to do a quick value assessment to understand if you should give it a try. You can start by reviewing Agile Manifesto (value proposition). You should also review high-level methodology. If Agile can add value to your organization, then you are ready to take your relationship to the next level.

1.2) Dating
As you continue to feel that Agile and your organization are a good match, it is high time to test this relationship by doing a small pilot. Pick a project team, which is best suitable for Agile. Let this team explore Agile principals to help you validate the value proposition. You may need to make a small investment to support this pilot team for them to try new things e.g. infrastructure for automatic daily builds. If possible get a part-time coach to guide this team through the pilot.

1.3) Engage
Don’t let this pilot run endlessly. At some point of time you need to make a decision if it is worth committing on a long-term basis. The pilot should be able to provide you with data points to make this decision.

Phase 2: Commit (Exchange Vows)
Once an organization decides to “Engage” formally with Agile, it is very important to “Exchange Vows” for sustained relationship. It is critical that leaders of the organization understand commitments they need to fulfill. Success cannot be achieved without fulfilling these commitments. Here is a list of key commitments:

Commit to change: Agile is all about embracing change, hence, organization should be prepared for cultural changes. Transition plan for the change should be created and necessity of the change should be communicated.
Commit to trust & collaborate: Trust and collaboration are key building blocks of any relationship. Your relationship with Agile is no exception. Trust is needed to promote a culture of self-organization whereas collaboration is needed to support a culture of Trust.
Commit to invest in the relationship: Agile is very demanding. It is attractive due to its tool-kit of engineering best practices. You need to invest in this tool-kit to keep Agile attractive forever. You will also need to invest in experts who shall make this journey comfortable.
Commit to inspect and adapt: No relationship or process is perfect. Perfection comes from continuous inspection and adaptation.
Commit to stay together: It is a natural tendency to gravitate towards other attractions, however, it is important to stay with your “first” choice. If you opted for “Scrum” then avoid “Scrum-But” to yield expected benefits.
Celebrate: Last but not the least, don’t forget to celebrate. Cherish your decision and get ready for a value driven journey.

Phase 3: Transform (Mature Bonding)
This phase is focused on settling down in the relationship i.e. stand-up together every morning, invest incrementally for the betterment of life, share likes-dislikes, collaborate and adjust. This simple philosophy transforms individuals into a well-functioning team.

3.1) Incremental Investment
Process of transformation requires some investment to create a stable base. If you need a brick-house then you need to invest in bricks. You cannot get desired stability by using sticks instead of bricks. Similarly, Agile needs key building blocks to provide you with a most stable and value driven culture. You don’t need to invest everything up-front. Your teams need to continuously inspect and make right investment choices to adapt. Following are the key investment areas:

Training/Coaching – Validate approach and expedite learning
Cross-Functional Teams – Avoid Silos to increase collaboration and self-organization
Engineering Best Practices – Forget about agile if you can’t build, deploy and test daily
Tools & Infrastructure – Do you have sufficient infrastructure to support automation and various kinds of testing? Will an Agile tool help to reinforce key principals?

3.2) Inspect & Adapt
Agile’s iterative nature provides an opportunity to observe how things progress on a daily basis. In addition, it also provides an opportunity to review the whole iteration and decide on ways of improvement at the end of each iteration. If we observe the right things and make the right choices, then we can improve as much as we want. Unfortunately, we were not born knowing the right things to observe. That’s why “inspect and adapt” plays a key role in transformation. A few things you may wish to inspect more closely are:

Relationship (Process) Maturity: It is hard for teams to understand practical value of the agile concepts in the beginning. Teams can create a Agile Maturity Scorecard and review it after every iteration to take incremental improvement steps until they mature in all areas. Scorecard is a useful way of answering the question: "are you doing Agile?". There is much more to high-performance than just following the process.
Agile Attitude: This is the hardest part of the adoption process, which may take a long time to fix esp. at the management level. Here are the key elements of Agile Attitude:

- Change is the norm, not the exception

- Reality rules, not the project plan

- The future drives the baseline, not the past

- The process serves the people - it does not handcuff them

- Leading takes precedence over managing

Self-Realization: Iterative nature of the process helps people gain efficiency by self-realization. Daily standup meetings and frequent retrospectives make people more receptive for constructive feedback and continuous improvements. This part of the Agile plays main role in transforming good teams to hyper-productive teams.

Goals and Expectations: Agile adoption goals should be reviewed on a regular basis as the targets may change with continuous learning. It is important to set the right expectations for the stakeholders.

Phase 4: Expand (Grow Family)
This phase is focused on enjoying fruits of hard work of the previous phase. It is time to grow and celebrate.

Expand Business: Agile drives faster time to market, which results in bigger business opportunities.
Expand Portfolio: Agile results in low cost of doing change, which increases operational efficiency to expand portfolio
Expand Agile Adoption: Agile builds hyper-productive teams, which set a good example for others to follow.

RULE OF THUMB:
In a nutshell, Agile is a perfect partner and this partnering brings a radical shift and a big cultural change. If you are the change agent in your organization then don't wait! Date with Agile for sometime and decide if you are made for each other. Like any other relationship, Agile relationship will have its ups and downs as you get used to each other. Always remember, "Winners never quit." They “inspect and adapt” and find better ways of getting the best out of the relationship. I wish you all the best – Explore, Commit, Transform & Expand the Agile Family.

Related Articles

You can watch agile educational videos at Agile TV. Here are Agile TV channels:

Other Cool Articles:

Agile Planning - Backlog Management

noreply@blogger.com (Yogesh Kumar) — Wed, 15 Jun 2011 21:38:00 +0000

Agile has not only reinforced the interest in project management, but also challenged the conventional ideas about such management. It focuses on project management institutions where it is difficult to plan ahead with mechanisms for empirical process control, such as where feedback loops constitute the core element of product development compared to traditional command-and-control-oriented management. It represents a radically new approach for planning and managing requirements a.k.a. backlog management, bringing decision-making authority to the level of operation properties and certainties.

The following video not only compares Agile backlog management with traditional backlog management, but also explains agile planning process in detail. Here is the youtube link for the video,

Related Articles

You can watch more agile educational videos at Agile TV. Here are Agile TV channels:

Agile Retrospective: Journey of an Agile Team

noreply@blogger.com (Yogesh Kumar) — Tue, 10 May 2011 20:11:00 +0000

Agile brings a lot of behavioral and process changes, hence, adoption does not happen overnight. It takes a considerable amount of time for teams to iteratively understand and experience agile concepts. As a matter of fact, 2-4 weeks iterations (sprints) attract most of the teams wanting to be agile. Teams start iterating without clearly understanding value of other key agile concepts e.g. burndown charts, backlog management, definition of done, estimation practices etc. These teams start appreciating implementation problems through retrospectives. This appreciation for the problems also makes it easier for teams to learn agile techniques to solve problems incrementally.

Each team is different and there agile journeys may differ too. There are no silver bullets for perfect implementation. Retrospectives play a key role for the sustained adoption. This video case study represents a typical journey (milestones) of an agile team that I have experienced in various agile adoptions. You may find it useful too.

Click below to watch embedded video. You can also watch youtube version of this video.

Related Articles

Agile Movie Trailer - A Change Agent

noreply@blogger.com (Yogesh Kumar) — Tue, 03 May 2011 21:08:00 +0000

This short and entertaining video provides a quick introduction of the Agile process. This must watch video is an inspiration for Agile Experts and a good starting point for Agile Newbies. This takes you from the ancient history of software development process to the state-of-art Agile processes. You can also watch this video at youtube. Have Fun and share your feedback!

If you wish to learn concepts highlighted in this video then review the follow articles/videos:

Agile Iteration Lifecycle

noreply@blogger.com (Yogesh Kumar) — Tue, 03 May 2011 03:25:00 +0000

In this innovative video blog, Virtual Mr. Agile is helping an agile team through a series of live discussions with the team members to explain Agile iteration lifecycle. These discussions cover many topics such as agile manifesto, sprint "0", role of scrum master, definition of ready and done etc. You can watch more videos at community video channel.

Here is the high level agenda covered in this video blog:

Related Articles

You can watch more agile educational videos at Agile TV. Here are Agile TV channels:

Agile Governance

noreply@blogger.com (Yogesh Kumar, CSM, CSP, PMP) — Mon, 02 May 2011 04:08:00 +0000

Businesses worldwide, are experiencing a common phenomenon - increasing change, uncertainty and unpredictability in the business environment. And the situation is not going to get any better - in fact it's going to get worse. Large uncertainties and unpredictability are fast becoming the norms of everyday life.

Businesses don't like surprises. And they don't like surprises because surprises can be dangerous. Unexpected changes can harm a business because enterprises are fragile - they are easily damaged and broken by unexpected and unpredictable changes and events.

How can we deal with this problem? We can solve it by building an enterprise that is not easily damaged and broken by unexpected and unpredictable changes and events. An enterprise that is agile to rapidly adapt to tomorrow's surprises. It is not easy to create such an enterprise because it requires the development of a whole new set of business practices as well as radical changes across the whole enterprise.

Note that agility is not just about speed of response - it is about rapid adaptation. In other words, enterprise elements adapting in response to unexpected and unpredictable changes and events, new opportunities and customer requirements, new technologies and changes to industry structures.

What is an Agile Enterprise?
An agile enterprise is a fast moving, adaptable and robust business. It is capable of rapid adaptation in response to unexpected and unpredicted changes and events, market opportunities, and customer requirements. Such a business is founded on processes and structures that facilitate speed, adaptation and robustness and that deliver a coordinated enterprise that is capable of achieving competitive performance in a highly dynamic and unpredictable business environment.

How do we build Agile Enterprises?
It requires strategic vision to commit to embracing the emerging business environment. This involves creating an agile strategy that manifests principles of adaptation across the value chain. An enterprise's agility drastically reduces if only part of the value chain is agile, hence, an Agile Enterprise needs an Agile Governance to drive Agility across the organization. Purpose of this governance is not to control. Its main function is to ensure alignment of agile execution with agile strategy. It also takes responsibility of investing in team's agility. This agile governance needs to be very "lightweight" to justify agility of the process. In this article we will focus on how to create an Agile Governance as a building block for an Agile Enterprise.

How can we create lightweight Agile governance without compromising Agility?
In order to understand Agile Governance, you need to understand the following two key concepts:

Communities of Practice (CoPs)
Scrum of Scrum (SoS)

I highly recommend you to review these concepts because these are the backbone of the Agile Governance.

1. Communities of Practice

What are CoPs?

Communities of practice (CoP) are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.

What are the characteristics of CoPs?

Formally committed to an organizational domain e.g. architecture, user experience, quality assurance etc.
A virtual team with shared interest and competence spans across multiple agile teams with a community "lead”
Self-organizing
Carry a community backlog
Building block for Agile Governance

What are the benefits of CoPs?

Define domain roadmap
Promote best practices
Manage domain dependencies across teams
Coordination and synergy
Mapping knowledge and identifying gaps
Knowledge sharing and problem solving

Finally, how does these CoPs help in Agile governance?
Imagine a software project (some may call it a program) where you have 8 Agile teams working on delivering a single product. As you can easily guess, this project will have some common elements and lot of integration points. As an example, all teams need common user management, consistent look and feel, consistent error handling, common QA practices, and moreover a unified architecture to deliver a well integrated projects. Obviously, project needs multiple architects, UI designers and QA folks. It is old fashioned to create a dedicated team for each functional domain e.g. architects or UI designers or QA folks. It is too unproductive and non-agile to put these smart guys virtually away from the real teams. What can we do to bring the agility in team structure? We just need two simple steps:

Ensure that folks in these functional domains are cross-functional and hands-on while maintaining their area of expertise.
Convert your dedicated domain teams into virtual teams and make these domain specific folks part of the agile teams focusing on specific business capability. Each Agile team has people capable of software design, UI design, QA etc. In other words, create virtual CoPs who virtually maintain their domain specific backlog while each member of this CoP becomes part of some Agile team. Each CoP has a lead who functions more like a domain product owner. These CoPs must be self-organizing.

2. Scrum of Scrum (SoS)
So far so good, we solved the problem of creating silos while developing cross-functional agile teams, however, we also introduced a new dimension by team virtualization. How do we ensure that these virtual teams are functioning well? How can we make these virtual teams more scalable?

Let's introduce another concept called Scrum of Scrum (SoS), which helps in making Agile Governance scalable. SoS is introduced by Scrum but you can apply this concept in any Agile format.

The scrum of scrums (SoS) is an important technique in scaling Scrum to large project teams. This concept allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration. SoS creates an virtual environment to members of various Scrum teams to function as Scrum of Scrum.

3. Agile Governance
As you will notice that CoP and SoS are similar concepts (virtual) but with slight difference (vertical - skill domains v/s horizontal - business function). Both concepts are used by many Agile teams. We can make process even more scalable by merging these concepts together. This merger provides us an Agile Governance which focuses on the strategic element of the organizations. Here are the key characteristics of an Agile governance:

Key building block for an Agile Enterprise
Focuses on integrating value
Aligns agile strategy with agile execution
Driving force for the agile strategy and business success
Invests in the predictable delivery (e.g. training, coaching, certification, engineering best practices, tools etc.)
Nurtures innovation
An extension of SoS and CoP concepts
Consists of PMO, Business and CoP Leads

As you will notice in the following diagram, you can implement SoS horizontally for the Agile Governance and Vertically for the CoPs. This approach makes CoPs more effective and CoP leaders make Agile governance highly effective.

If you need to extend this governance further in a highly distributed environment or to an contracting environment, then you may apply another concept called "Proxy Product Owners". Simply speaking, if main Product Owner cannot participate actively in your agile teams then you may assign a Proxy who represents Product Owner in the Agile team. This proxy needs to maintain a very good communication with the Product owner. There are pros and cons for this concept, hence, it needs to be applied carefully.

RULE OF THUMB:
In a nutshell, Agile Governance is based on following three basic concepts. It is not mandatory that all 3 are required to be implemented. It largely depends on the complexity of your project and organization. Ultimate objective of the Agile governance is to make Agile process more scalable without loosing focus on integration and strategy of the enterprise.

Develop and cultivate Communities of Practice (CoP) (virtual skill domains)
Use Scrum of Scrum as necessary (virtual process management)
Use proxy for product owners if there is no viable way to have product owners participate in the Agile team meetings

Agile Development Teams: Scope and Scale with Mike Cohn

Related Articles

You can watch agile educational videos at Agile TV. Here are Agile TV channels:

References:

Feedback is welcomed!

Agile Team's Efficiency in Various Resource Allocation Models

noreply@blogger.com (Yogesh Kumar) — Sun, 01 May 2011 04:30:00 +0000

It is important for resource and portfolio managers to understand how various resource allocation models impact team efficiency and scalability. Let's review few resourcing models used by portfolio/resource managers. Later on we will also review simple metrics to gauge team efficiency and scalability.

RESOURCING MODELS

1. Resource Pool Model
It is a typical model where all resources in the organization are part of a common resource pool. In this model, product teams do not have fixed resources. Each new release of the product initiates a new resource request. Based on resource availability in the pool, resources are assigned to the project. This may result in changed team for each release . This model creates a consulting syndrome where people only focus on immediate work with no real motivation to think about product vision and long team performance. Also, resource allocation is loosely coupled with skill match for project needs. Pools are normally segregated by expertise e.g. QA, User experience etc. This results in less cross-functional team members. Unsurprisingly, this is the most commonly used model.

2. Split Resource Pool Model
This model is a variation of resource pool model. In this model, team members may not even have one-to-one project allocation. Resources can be assigned to multiple projects at the same time. This introduces another side-effect as people tend to loose efficiency when they multi-task on multiple projects with varying priorities.

3. Agile Resourcing Model
This model is generally driven from the product vision. A dedicated investment is made to develop a cross-functional team with right expertise for the product development. Investment is incremental as product meets revenue or other goals. Key focus is on building core product team with deep product and technology knowledge. This model works well with incremental agile approach.

You can find many other variation of these resourcing models. Main intent of this article is to help you understand efficiency and scalability caused by the resource changes.

TEAM EFFICIENCY METRICS

1. Team Efficiency Quotient (TEQ)
Building a team is a complex process. Enough is written about it already. I just want to stress that there is a cost associated with building a new team. We can't avoid it but we can minimize the impact by selecting team members with appropriate skills and attitude. Each time we make a change - addition or replacement - it brings efficiency of the existing team down for some time. This happens because team helps new people to ramp up knowledge and to get them used to the new environment.

Realistically, how much can a person contribute if he joins project in the last month? In my experience, this person can hardly contribute to the project deliverable, instead he brings down velocity of other team members temporarily. We can simply quantify team efficiency as:

TEQ = Average time spent by team on the project

e.g. You utilized 10 resources for 4 months project.
- 4 resources joined in the beginning
- 4 resources joined after 2 months (50% project left)
- 2 resources joined in the last month of the project (25% project left)

TEQ = ( 4*1 + 4*0.5 + 2*0.25)/ 10 = 0.65 = 65%

In Split Resource Pool Model, this efficiency goes down even further because people loose efficiency because of multi-tasking.

2. Team Scalability Quotient (TSQ)
Once you build a good team, it is easier to scale it as product needs grow. If you constantly rotate team members than scalability of the team reduces as continuity is constantly broken between releases. The following TSQ metrics is mainly targeted to gauge impact of team changes between releases. There are many other factors contribute to team scalability but those are out-of-scope for this article.

TSQ = % of the team retained from the previous release

In TEQ example, we built a team of 10 people. Team had low efficiency because of ramp-up but we can assume that team is ready to take on next version of the product. Team gained good product and technology knowledge. They finally got synergy as a team. Let's say if you replace half of the team members with newer members to work on the new product release then it reduces team scalability by 50%.

In a nutshell, portfolio and resource managers should carefully consider how resource allocation impacts team efficiency and scalability. Please think, if you are building teams or consultants. If you are really keen in making agile successful then invest more in developing cross-functional teams. An agile team gains velocity as team dynamics improves. If you keep disrupting teams, then don't expect your agile teams to gain velocity. Choice is yours!

More Articles

Beware of holes in your organization

noreply@blogger.com (Yogesh Kumar) — Sun, 01 May 2011 03:23:00 +0000

Managers at all levels can run into many roadblocks. To attain the goals of the organization, managers must overcome obstacles. However, they often swipe at shadows and do not clear the root causes that burden their organizations. Problems are often dealt with by addressing the consequences of issues instead of the issues. These “workarounds” do not last because they allow the root causes to remain “in play”—further harming the organization.

Sometimes, management’s workday can seem like that game where a child hits a peg with a mallet only to have another peg pop up elsewhere on the board—never making any progress. Problems snowball out-of-control and managers become frustrated and perhaps even apathetic. They reach the point where putting a finger in a hole in the dike is considered a successful solution, even though the dike is cracking elsewhere.

No one has the time, resources or perhaps knowledge to search for, identify and then terminate root causes of problems. Organizations ends up creating big holes while wrapping those under a thin layer of workarounds. These holes can drag organizations down or can impede their rise. Even if an organization is prospering, it might not be prospering to the degree it could be if it is afflicted with more holes.

Topic of "rules of holes" is started by Thomas Cagley on twitter by sharing first rule of holes. Mike Hesketh made a significant contribution by sharing more rules. This is an important topic, hence, I thought of blending serious topic with some humor. Thanks Thomas and Mike. Your feedback is welcomed!

Here is a list of rules of holes we came up with. I am sure these are not new and many other may have written about these. I hope you will find these helpful.

DESTRUCTIVE RULES OF HOLES

If you find yourself in a hole, stop digging. When you dig a deep enough hole, it may become your own grave, hence, never refill hole while you are still in it!
Holes Happen! They can appear out of nowhere, full blown. One minute they're not there and the next thing you're in one, like when a coder check-in bad code and goes on vacation, or when your lab encounters unplanned outage. A wise person always carries a ladder.
Holes only go down. Holes that go up are called piles. The higher the pile you shovel, the more likely it is to fall on your head someday.
Bottomless holes are called pits, as in endlessly throwing good money into one.
People seem to love to build replacement holes. After they manage to climb out of addiction holes (code but test only in the end), bad relationship holes (political alliances) etc, they often dig themselves into another one just like it.

CONSTRUCTIVE RULES OF HOLES

Holes are only vertical. Horizontal holes are called tunnels which may lead to the light at the end of the tunnel.
If you fall down in a hole you tend to look out for the next one.
When you see someone in a hole, help them out; don't gloat.
Sometimes holes can be your friend; for instance in a storm. But it's important to know what kind of storm is coming. In a tornado, holes are good; they are not so good in a flood. Use holes as an opportunity to take your organization to the next level of success.

In a nutshell, holes are part of life. You can't avoid those. Beware of holes so that you can reduce chances of falling in those. Even if you fall down, you must carry a ladder to take you out. Don't just look for "workarounds". Identify "root causes" so that you can make organization a better place to work. Good Luck!

Reference: Black Holes and Management By Ron Lutka

More Articles

Coping With The Loss of Waterfall

noreply@blogger.com (Yogesh Kumar) — Sat, 30 Apr 2011 16:56:00 +0000

The Five Stages Of Grief by Ion Moldoveanu

A change, and in particular cultural change in a big organization, is never easy. Therefore there are many models defined to help the change managers and ease the transition. Kotter’s 8 step change model is one such example. While researching, I found only few of these models support the experiences of those impacted by a change. I came across a model from an unexpected source “The Five Stages of Grief” by Kübler-Ross[1]. This model applies to the fear of death or other tragic losses. They say fear of public speaking is higher than the fear of death. What about the fear of change?

Kubler-Ross has named the following five stages of grief people go through following a serious loss including the loss of waterfall. It is like the death of an old rigid mentality, which results in the starting of the nimble Scrum process. Sometimes people get stuck in one of the first four stages. Their lives can be painful until they move to the fifth stage - acceptance.

Denial: Our processes, or sometimes lack of it, works fine. We have been doing the same thing for many years. There are some usual problems but everybody is used to the existing practices. Scrum does not work for our projects, so it does not even make sense to try.
Anger: Why is this happening to me? I used to be comfortable with a long and rigid process. There was always somebody to blame and not much change going on. I used to be an authority in the old system, now I have to go back to school.
Bargaining: This project has already started. Let’s go to agile next time. This does not work for the particular project I am working on because it does not have very much UI.
Depression: What am I going to do from now on? I will wait and probably this will go away. I know after all this agile thinking is going to fail because of scope creep.
Acceptance: Everybody is doing it these days. I cannot fight anymore. Better adapt to it rather than fight. It will at least look good in my CV.

The steps do not happen in the strict chronological order and different people may not experience all stages or the same intensity. Early adopters will jump form a short denial to become change agents while laggers will be stuck in denial.

During grief, it is common to have many conflicting feelings. Sorrow, anger, loneliness, sadness, shame, anxiety, and guilt often accompany serious losses. Having so many strong feelings can be very stressful. Yet denying the feelings, and failing to work through the five stages of grief, is harder on the body and mind than going through them.

Grieving and its stresses pass more quickly, with good self-care habits and implementation of the best practices e.g. unit testing, continuous integration etc. It also helps to have a close circle of agile family or friends to guide through the stages.

Kübler-Ross models how people cope with a tragedy like dying, divorce, diseases. Why do then many organizations react to change and in particular to agile as if they are losing somebody? The paradox is that we are afraid of such changes and fail to remember the basic law of nature, “only the species those are able to adapt shall survive”.

Note: The classification is done based on personal observations of people around me as well as my own reactions. It is not based on any formal survey.

About the Author
I, Ion Moldoveanu, am a software development manager in Oracle. I am passionate about all things that require an open mind such as innovation, leading change, self-development as well as building new skills capabilities in teams.

[1] Kübler-Ross, E. (1969) On Death and Dying, Routledge, ISBN 0415040159

Mr. Agile is explaining definition of done

noreply@blogger.com (Yogesh Kumar) — Mon, 18 Apr 2011 14:26:00 +0000

Mr. Agile is explaining definition of done to Amy in his latest discussion in the office xerox room. Enjoy this cool video and let Mr. Agile know if you have any question about Agile.

Transcript:

Amy: Hello Mr. Agile. Is there any good way of articulating end of the sprint?
Mr. Agile: Hello Amy. It's a good question. Ideally, each team should have their definition of DONE at 3 levels:

Story,
Sprint, and
Release

Amy: What's the importance of DONE in Agile?
Mr. Agile: DONE is equal to "value" in Agile. If you need your team to deliver "value" then you better define "done" with your team. Poor definition of done means poor value in the end.

Amy: Is there any standard Definition of DONE?
Mr. Agile: NO. It is a joint commitment that team agrees to deliver at the 3 levels I just explained. Team should have a shared meaning of "Done". RULE OF THUMB is:

Team has a common understanding of what DONE means at user story, sprint, and release level.
It follows agreed discipline.
Deliverables of the team are incremented with each iteration - from release notes to software to technical documentation - to the degree necessary to support release.
Team delivers potentially shippable product at the end of the sprint. This discussion is presented by Agile Helpline.

Amy: Thanks Mr. Agile and Agile Helpline for your Agile Bites.

References

Definition of Done - Rule of Thumb [rule]
Agile Rules of Thumb [rules]
10 Scrum Rules [article]
Featured Articles [articles]

Mr. Agile talking about user story readiness

noreply@blogger.com (Yogesh Kumar) — Mon, 18 Apr 2011 03:46:00 +0000

Mr. Agile is talking about user story readiness to Sarah in Agile Helpline series of Agile Bites. Enjoy this cool video and let Mr. Agile know if you would like to learn about any specific Agile topic.

Transcript:

Sarah: Hello Mr. Agile, How are you doing? I have a question for you. In agile, when do you consider something ready to implement?

Mr. Agile: I am doing very well Sarah. In agile, we have 3 stages of readiness:

User Story is READY if a team can implement it, and a Product Owner can prioritize it.
The Backlog is READY when about 1.5-2 times Sprint's worth of User Stories at the top of the backlog is READY, and those user stories are sufficiently small to fit in a sprint.
Team is READY when every team member is self-organized.

Sarah: That's very interesting and helpful Mr. Agile. Can you please explain more about user story readiness?

Mr. Agile: A User Story can be considered READY if:

It is defined as need, conversations, and confirmations and has unique priority in relation to every other story in the product backlog.
It follows INVEST principals, which means a story is independent, negotiable, valuable, estimable, and testable.
It has been estimated (in story points) by the team.
It is small enough to fit inside a sprint. Larger stories should be reformulated and splitted before the sprint planning to be considered "Ready".
It does not have any known dependency that can block the completion of story.

In a nutshell, don't let anything that's not READY into your Sprint, and let nothing escape that's not DONE. This conversation is sponsored by Agile Helpline.

References:

Definition of READY [article]
Definition of DONE [article]
Agile Rules of Thumb [rules]
User story and backlog management [article]
Featured Articles [articles]

Agile Strategy Manifesto Video

noreply@blogger.com (Yogesh Kumar) — Fri, 15 Apr 2011 01:49:00 +0000

The following animated video presents Agile Strategy Manifesto. Here are the key learning objectives:

What is Agile Strategy Manifesto?
What are the four phases of Agile Strategy?
What are value spirals and strategy curves?
A case study of Agile Strategy

Here is the YouTube version of the video:

References

The value sphere by John A. Boquist
Innovation diffusion and innovation decision process model by Rogers
Competitive advantage: creating and sustaining superior performance by Michael E. Porter
Innovation Lifecycles by Soren Kalpen

Suggested Agile Reading:

Goodbye Winters - A Non-Agile Project Done In An Agile Fashion

noreply@blogger.com (Yogesh Kumar, CSP, CSM, PMP) — Sat, 09 Apr 2011 16:49:00 +0000

Photo and video editing is one of my hobby that you guys may have noticed in my previous blogs. This time I applied Agile concepts to one of my personal projects. Video editing can be pretty time consuming efforts, hence I decided not to take it as a crazy night time project. Instead, I allocated 1 hour a day for a week to complete the project with continuous feedback cycle. Daily tasks that I planned were:

Learn iMovie advanced features (Fri)
Shoot a video (Sat)
Breakdown video in scenes (Sun)
Fine tune scene length (Mon)
Familiarize with various Jam packs and audio loops for audio effect (Tue)
Mix audio loops with Videos (Wed)
Final edits and publish (Thu)

Here is the outcome of one week of disciplined learning and fun:

Apple Store and my daughter were the key stakeholders who provided me constant feedback. Thanks Jon (Apple personal project trainer) and Anika for being a great help. BTW, Apple One2One training is awesome if you want to learn their professional tools. This is the best 99$ I have spent in my life for a year long training.

How to deal with business requirement documents?

noreply@blogger.com (Yogesh Kumar) — Thu, 07 Apr 2011 20:15:00 +0000

It is interesting that organizations send few folks for Agile trainings such as ScrumMaster but don't have any plans to become Agile. For some managers, it is just about meeting their training goals. Here is a typical scenario where business just handed over a big business requirement document (BRD) document with lots of requirement to this theoretically trained ScrumMaster. A common reaction from the ScrumMaster new to the agile world is not positive. He thinks, how can he change BRD focused environment to an Agile environment? It's challenging and frustrating. Should he give up?

True that environment is challenging but remember "winners don't quit". They use common sense. I also call it ScrumSense. Let's review how you can give a positive twist to this scenario using my rules of thumb.

Lucky you, you just got a list of product backlog. Many teams doesn't even have such a backlog. Be happy and do a very high level estimation of the backlog. Normally, you don't need to estimate the entire product backlog in the Agile process but your team is not Agile yet, hence, you need to estimate backlog anyways. Trick is to first do a very high level estimate to save efforts.
High level estimates may suggest that release will need few months to complete - let's say estimate is 9 months. This is another good news because you have an opportunity to impress your team by demonstrating agile value proposition. Ask business if they need all functionality after 9 months OR if they will be happier if you deliver them entire functionality in 3 releases in 3 months iterations. I will be surprised if business rejects this offer of getting value incrementally.
Next step is to ask business to provide a stack-ranked list of functionality so that you can pick up top priority items for the first mini-release. This list becomes your release backlog and remaining stack-ranked functionality becomes product backlog. If your engineering team is capable then you can do monthly sprints and do demo to the stakeholders after every sprint. In any case, I am sure that you will agree that planning for 3 months is more realistic then planning for 9 months.
Now you are in the last week of the mini-release assuming you are almost ready to do first mini-release. Ask your business if you can take highest priority items from the remaining product backlog for the mini-release #2. What do you think will be the answer? Try and experience it. I tried it many times and I consistently get the same message:

"Business priorities have been changed and we have a different list of functionality to implement. We like this iterative process."

As a leader, take responsibility of demonstrating to your organization that change is the only constant. Let's embrace it and think iteratively. This could be a good beginning for your agile journey. Good Luck!

Mr. Agile explaining to Mike how to help business to be agile.

References:

Featured Articles [articles]
Agile Rules of Thumb [rules]
Agile Resources [learn]

Agile investment - where to start?

noreply@blogger.com (Yogesh Kumar) — Thu, 07 Apr 2011 16:50:00 +0000

I have noticed an increasing trend that software development teams, venturing into agile world, do their first investment in Scrum training. Is it a wise investment? Does it provide a good rate of return?

Absolutely NOT!

Scrum does not make teams agile. It teaches how to get the best results from an agile team. Agile and Scrum are related but these are not synonyms. Agile is foundation and scrum is structure. A wise person invests first in a solid foundation.

If I have limited budget then I will invest money in the following order:

0. Agile Coach: If someone decides to go to a new destination. There are two options:

Adventure: Explore, learn, and keep going (inspect and adapt).
Guided tour: Someone knowledgeable can make your journey easy and enjoyable

Both techniques have advantage and disadvantages. Investing in an agile coach can make agile journey easier and teams can start yielding returns very quickly. Inspect and adapt can work very well for smaller teams. I highly recommend large teams to invest in a agile coach to avoid chaos and dissatisfaction. Agile coaches architect a solid foundation.

1.0 Unit testing: No extra investment is needed. Just need an attitude change and engineering discipline.

1.1 Continuous integration: I will hire/develop an expert release engineer or configuration manager who can automate build and deployment process with the objective of daily integration build deployed for daily testing.

1.2 Infrastructure: It is critical to have enough hardware to support continuous integration environments. In real world one environment is not enough to meet all our needs (user acceptance testing, performance testing etc.).

2. QA Automation: It is important to understand how teams will make use of daily deployments. If testing is manual than cost of testing will shoot up very quickly as teams have lot more to test now. It is critical to invest in QA automation to take advantage of frequent deployments so that defects can be caught quickly.

3. Process Training (e.g. Scrum): If a team can't not meet the above mentioned prerequisites then Scrum or any other process can't make much difference. Hence, why should I bother about training team for Scrum. A solid structure based on a week foundation falls apart sooner or later. Also, cost of fixing weak foundation, after a structure is built on it, is much higher. On a positive note, teams atleast realize that their foundation is weak after going on a Scrum path. For some people, failure is the way to learn. Hence, it is fine to start on Scrum path just to learn the importance of solid engineering foundation.

How will you invest your money if you limited budget?

Suggested Agile Reading:

Agile Continuous Planning

noreply@blogger.com (Yogesh Kumar) — Fri, 01 Apr 2011 17:32:00 +0000

This is the final and one of the most critical layer of the Agile Planning Onion. Agile product development teams are constantly driving towards a state of continuous, adaptive planning, collaboration, design, development, testing and integration. This commitment fosters a dynamic, highly productive environment in which automation is critical and the output is always high-quality, valuable working software. You can read more about continuous integration In Matin Fowler's article.

You can review the Agile Planning Onion by clicking on the following diagram. I recommend to watch this video to get a better understanding of linkage between all layers.

Agile Planning Onion Layers

Agile Daily Planning

noreply@blogger.com (Yogesh Kumar) — Fri, 01 Apr 2011 17:30:00 +0000

This is the fifth layer of Agile Planning Onion. Every day the team is focused on completing the highest priority features in the form of working, tested software. As features are delivered within the iteration, they are reviewed and accepted, if appropriate, by the product owner. Each day a short, 15-minute standup meeting facilitates the communication of individual detailed status and any impediments or issues. Product is integrated and tested on a daily basis. Burndown charts are the key tool for the team to review progress on a daily basis. These charts help teams to take corrective actions quickly.

You can review the next planning layer by clicking on the following diagram. I recommend to watch this video to get a better understanding of linkage between all layers.

Agile Planning Onion Layers

Agile Iteration Planning

noreply@blogger.com (Yogesh Kumar) — Fri, 01 Apr 2011 17:28:00 +0000

Iteration planning is the fourth layer of Agile Planning Onion. Also known as Sprints, iterations are short, fixed-length subsets of releases, generally in the 1-4 week time frame. Iterations represent the execution heartbeat of the project. During each iteration the team's goal is to deliver potentially shippable software. Iterations incorporate three key phases:

Ready (backlog grooming, iteration planning)
Remove impediments throughout the execution (daily standup meeting)
Done - usually agreed by the team as a definition of done (iteration review and retrospective)

You can review the next planning layer by clicking on the following diagram. I recommend to watch this video to get a better understanding of linkage between all layers.

Agile Planning Onion Layers