I love the Kung Fu Panda movies, hope you enjoy them too. Apart from the funny awesomeness of Po the panda, I love the subtle and not so subtle messages and quotes these movies contain. Here are few gems from Kung Fu Panda 3. I only saw it this week, so am sharing these now.

Rock like Po the panda!

Rock like Po the panda!

Image courtesy: https://www.flickr.com/photos/27474697@N08/2556889334/

1. When will you realize the more you take, the less you have? – Master Oogway to Kai (the beast)

When Kai tells Master Oogway that he has taken the chi of every master there is, Master Oogway pleads to Kai to realize this. There is virtue in giving; always give when you can! So how is this connected to agile? There are examples. It could be giving help to a struggling team member, or giving credit to someone else who deserves it, or giving someone encouragement for their effort, or giving someone any other type of support they need – mentally, physically and emotionally.

Look beyond yourself. There is great power in humility and kindness, it helps build strong relationships that help teams thrive.

2. If you only do what you can do, you’ll never be better than what you are. – Master Shifu to Po

This one is straightforward. A core tenet of agile is to keep challenging oneself to do better than today. Never cease to challenge the status quo, it is a key to customer and team happiness.

3. I have so much to learn! – Po after the party at the secret Panda village

Learning is essential for an agile mindset. Learning manifests itself everywhere. There is always more to it than meets the eye, but one should be willing to see beyond what is visible.

4. You gotta let the hill tell you where to roll. – Li, Po’s panda dad during Po’s training

This one is interesting. Agile mindset encourages to be courageous and to experiment. Let the results tell you what to do next. Surely there can be failures along the way. Accept successes and failures as normal events, but don’t let the causes become your excuses.

5. Feeling relaxed? Just let yourself fall into it – Li, Po’s panda dad during Po’s training

This is a natural deduction for the previous quote. Immerse yourself into the environment and let it guide your actions thoughtfully. Not only will you increase your chances of success, you will also tremendously increase the enjoyment you get from your experience.

That’s all for now! If you have more quotes to share from Kung Fu Panda or anywhere else, I would love hear 🙂

#agilefails - Firefighting is never easy!
Dealing with tough situations in product delivery is always a challenge!

There are usually multiple ways of dousing flames and fixing situations. Unfortunately for us, when we are in the thick of things, we often get carried away and adopt the first solution that comes to mind. They say that the road to hell is paved with good intentions!

Over the last few years, I have come to believe that best solutions are ones that balance our short term needs with our long term view.

I present #agilefails. These are examples of partial fixes that do not address the root cause of our problems. While each #agilefail may help relieve an immediate pain, it is insufficient in the long run. Click To Tweet

This list will likely grow and evolve as I continue to learn and discover.

A long-running project is getting delayed. We are struggling to deliver based on our estimates. #agilefail – Lets add new team members!

#2: A senior leader wants something new immediately. #agilefail – No conversation needed. Some of us must immediately start working on this new “opportunity”.

#3: Team is getting too big to manage. #agilefail – Let us create multiple component teams (with multiple dependencies) to manage them better.

#4: Too many meetings are eating up our productive time. #agilefail – First get rid of the retrospectives, then grooming, and eventually reduce stand-ups to few days a week.

#5: Testers only want to test, developers only want to develop. #agilefail – That makes sense, it is their career path after all. It’s our duty to encourage that behavior.

#6: Rock-star team member hoards knowledge and we are afraid of losing him/her. #agilefail – Ensure that our rock-star is happy and promoted, so that person does not leave.

#7: Too many stakeholders want something delivered. #agilefail – Stop the conversation, do not commit anything as we are too busy. -OR- Commit to everything and still make everyone wait.

#8: Not everyone understands the value of collaboration. #agilefail – Make our most expensive tech people as Scrum Masters.

#9: There is shortage of people with a particular skill-set in town. #agilefail – Training our teams will take too much time. Let us hire remote employees who will be experts. We will make them work like hell with multiple teams.

#10: We have a tough delivery date for a big new project. #agilefail – There is no time!! Get coding ASAP and work weekends if needed! We can understand customer needs as long as each team knows its own part. There is no time to spend on process either. Teams can do whatever they want.

My disclaimer: There is something to be said about what we can change and what we can’t in our situation. We may find that a partial fix may be a step in the right direction and enable us to have a deeper conversation about fixing the root cause.

What do you think? Have you faced any of these situations? What did you do, and what did you learn? What other #agilefails have you come across?


Firefighters image courtesy: https://pixabay.com/en/firefighters-training-live-fire-1147795/

Would life be easier if we did not have to think about planning? Let’s face it, whether it is about running our day to day routine or even something as simple as paying a visit to the neighborhood grocery store there is planning involved. Imagine taking a vacation without planning where you will go, what you will do while you are there, how long will stay and what you need to bring with you. Or imagine not thinking about how much you need to earn, to save and to invest to meet your worldly needs.. Well lets just keep those worries aside for a few minutes shall we and think about how planning can actually help! Yes that’s right, no matter how much burdensome it might sound, planning can help.

What is planning?

The simplest definition of planning that I have come across is “decide on and arrange in advance”. I like this because this definition is light, it does not say how much detail we need to plan in, but an important thing that it does say is that planning happens in advance.

Why plan?

There are many reasons why we plan. Our limited information about the future and vision of what we want to do with that information in order to achieve a specific objective gives us an opportunity to play with creative alternatives and paths to get there. Applying constraints helps us narrow down our search of solutions, breaking them down into chunks or steps that are (hopefully) easy to understand and sequence as necessary. When steps and solutions are not known we put on our experimentation hats and navigate our way to discovering the possibilities.

Use the plan as a defense strategy

So what should I tell my teams when they get planning? What are the things I need to keep in mind but don’t come easy, specially with Scrum? In my note to self, I include the following.

Plan just in time, and just enough..

Plan early but not too early. Have a high level roadmap that (can change and) tells the team the path we will take if things went all-right. Planning too much too soon could mean a lot of wasted effort and repetition. Planning too little could mean little predictability in outcomes for initiatives that span multiple sprints. So lets groom our backlog stories and have them ready for a few (may be two to four) sprints to come. Lets find that right balance for our team where Sprint planning sessions do not become painful and burdensome.

Plan based on data..

More often than note, teams are asked to meet an “aggressive targets”. In other words, there is a huge tendency to ask for deliveries tied to dates without understanding scope and effort involved. These dates are usually based on business constraints and are tight (more often than not). So, organizations and teams find themselves in situations where teams are unable to deliver as some say – “on time” and “within budget”. Lets avoid that for our team through scientific and consistent use of measures such as velocity and cycle time. Lets make forecasts based on data so that business understands our non-trivial effort and can make realistic, prudent decisions on scope and priority.

Maintain discipline, Estimate or #NoEstimate..

There is much debate on whether to do estimates or not. What seems more important to me than that debate is to agree on an approach that works for our team and for your organization and follow it with discipline. When we estimate, lets spend little time estimating, after all estimates do not produce value for customer, working software hopefully does. Estimates are just that – “estimates”, they are “not actuals”.

High priority, High risk first..

What should the team work on first and what should it work on later? There are multiple factors that decide this, chief among them are dependencies, customer feedback and risk. The product owner plays an important role balancing all aspects while deciding the order so that team delivers value while making continuous progress. So lets keep in mind the problem we are trying to solve, and order our backlog on the basis of that. Lets identify those things that are not clear and run spikes. Lets reduce the risk early as early as we can, so that we do not embarrass ourselves in front of our stakeholders and customers when the time comes.

Minimize hand-offs, eliminate technical debt..

Lots of times, teams work with other teams to deliver an experience or functionality. Many times this needs dependency management, and back and forth discussions. This can lead to side effects such as reduced velocity, need for additional testing to retain quality, development of interfaces and/or APIs etc. When we get into such situations, lets find out if we can minimize dependencies through techniques like creating mockups, and integrate early and often. Let us ferociously automate testing and deployment (at all levels) so that we can identify and resolve issues quickly.

Plan often and monitor, welcome change..

Lastly, should planning be one time? Absolutely not! The team should be ready to embrace change as they get better insights into customer needs and potential solutions. Lets dispassionately accept new stories, reject old ones that are no longer useful and update ones that need to be updated. Once again, an active Product owner and Team partnership can make a big difference. It is not as important to stick to the initial plan as it is to fulfill needs of the customers.

Related reading:

This article was first published by Scrum Alliance on July 22, 2013.

During the last few years, my view of how programs work has evolved. It has moved from viewing program management as traditional “old-school” handling of multiple projects and product portfolios (dry and boring) to seeing program management as a key to ensuring organization success that aligns the organization with its vision, strategy, and innovation. I think of program management as a crucial tool that makes an organization successful by pointing its entire energy and focus toward its most important initiatives and fulfilling its promise to customers, shareholders, and employees.

Why do organizations need programs?

“Programs are a group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually,” according to PMI. What do organizations have to gain by investing in coordinating and controlling multiple projects as a program? This is similar to asking what value program management brings to an organization.

A quick search on Google reveals various links on the topic. An article at chron.com lists the following: comprehensive view, work toward strategic goals, consistency, cost savings. An article at eHow.com lists supervision, organization, budgeting, funding, accountability, and delegation.

Program managers shepherd different teams and projects in the organization toward a common objective. These teams sometimes have different internal priorities, which can impact when and how they deliver their part of the program. Program managers help surface these issues and facilitate much-needed conversation around issues, risks, and mitigation to achieve a higher-level organizational goal (or a set of goals).

Streamlining various lines of work within the organization can translate into several financial and nonfinancial benefits, such as revenue generation through on-time market launches, avoided or reduced opportunity costs, reduced operational costs, higher customer goodwill and revenue retention, transparency, and even better employee engagement.

Simple or complex?

There are many factors that make programs simple or complex to execute, such as:
·         Number of projects
·         Dependencies
·         Size of project teams
·         Resource availability/capacity
·         Prioritization of the initiative
·         Degree to which roles and responsibilities of project teams are well defined
·         Communication flows between project teams that require less coordination
·         Processes followed by project teams
·         Degree of transparency between the teams
·         Silos within the organization
The world of strategic program management is usually complex. Simple programs are hard to find, unless you are a small organization with a tightly knit set of teams and only one or two objectives to work on. The reality is that things start becoming complex even in small or midsized organizations when there are multiple issues at play.

How does complexity impact programs?

As organizations grow in size, they usually spread their operations, increase the number of their product offerings, try to become more cost efficient, and create specialized units for different functional areas (marketing, finance, sales, legal, engineering, technical operations, customer support and service, business intelligence, etc.). This suggests that organizations should pay attention to their most important goals while structuring their programs. That can be difficult, as different functional groups of the organization may be working on multiple priorities that might be competing with each other.

How do Agile principles help in dealing with complexity?

 laid down along with the Agile Manifesto can be useful in addressing issues related to complexity of programs. Even though these principles are heavily colored with nuances of software development, they can be applied in addressing issues related to complex program management:
1.     Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Organizations usually have a strategy that is supposed to convey to its employees what is most important for its success in the coming period. This strategy usually includes what the leadership sees as most valuable to its customers. Organizations that manage successful programs are able to prioritize those programs as per their strategy and focus their energy into those initiatives that are most important to their customers.
2.     We welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage: Just as with software development teams using the Agile process, it is desirable that the rest of the teams are attuned to changing market conditions or new insights (whether external or internal to the organization) that might require the product or a service to take a different direction than initially conceived. If all teams are receptive to change, there is a greater chance that the needs of customers will remain the central focus.
3.     We deliver working software frequently, from every couple of weeks to every couple of months, with a preference for the shorter timescale. Just as Agile software development teams manage their work, such as working on small chunks, it makes sense for program teams to show off their work in short cycles so that the rest of the organization knows how the entire effort is progressing. Examples include iterations on sales and marketing strategy by the sales and marketing teams, iterations on customer communication/rollout planning by relevant teams, iterations on a new product or major functionality by the development teams.
4.     Businesspeople and developers must work together daily throughout the project. There is great value in understanding the business perspective while building software. The same is true for other functional groups within the organization, who may not be as involved in building the software as they are in maintaining it. If the development itself is complicated and there are multiple development teams involved, it becomes even more important to keep everyone aligned with business expectations so that the program progresses in the right direction.
5.     We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done: All teams involved in a strategic initiative need to be motivated to deliver as per customer needs. If the environment encourages favoritism instead of making decisions based on merit, there are chances that everyone will not give their best to fulfill the goal of the program, likely impacting it adversely.
6.     The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face-to-face communication impacts teams’ effectiveness by helping them build rapport and find solutions to bottlenecks and problems quickly. This is true for programs, even though it is much simpler to institutionalize daily face-to-face communication for a co-located team of five to seven people who are working on a single objective. While this is true, program teams should synchronize as often as they can and use technology to fill the gaps if they are not co-located.
7.     Working software is the primary measure of progress. This principle is most useful in complicated projects involving multiple software development teams. Even when other nondevelopment teams are involved in a program, software development is often on the critical path, and that is often where most of the costs are incurred. So it makes sense to measure and track the progress made on working software. Likewise, program teams should measure and track progress of other non-software development deliverables that are required for readiness to deliver the product or service to the end users (launch readiness).
8.     Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. From the program management perspective, all teams should maintain and deliver at a pace based on the work needed to satisfy the program objective. In many situations, one team might start its work after another team has delivered. For example, the team in charge of invoicing may only be able to update the boilerplate of a product after that product is ready and the legal team has delivered the boilerplate to them. Dependencies such as this need to be tackled by program managers, along with the teams, when planning cross-team programs. When program management is sustainable, dependencies surface regularly and are addressed routinely — kind of like the way it works within a small Scrum team, where those dependencies surface and are resolved on a daily basis.
9.     Continuous attention to technical excellence and good design enhances agility. There is a balance between doing the right things and doing things right. When in a rush, teams may be tempted to cut corners in order to deliver on time. Sometimes this tendency might be driven by a business need that cannot be overruled, and teams are forced to take shortcuts. When this happens, teams must identify and track this as debt that they need to repay at a later stage (sooner is better, as with any debt that incurs an interest cost). Repaying debt regularly and doing things right ensures that the team does not slow down (or become bankrupt!).
10.  Simplicity — the art of maximizing the amount of work not done — is essential. Even in case of complex programs, organizations should strive for simplicity. Transparency and visibility are needed in order to create simplicity and maintain the flow of work between teams.
11.  The best architectures, requirements, and designs emerge from self-organizing teams. Agile encourages self-organization, which can be useful when managing programs. For multiple teams, this starts to happen when the each team is considered a unit and the overarching program team is considered the team that needs to reorganize. This is a question of mind-set and is in some ways easier to understand in case of small teams. When multiple teams are involved and each of them has slightly different (at times divergent) goals, self-organization can be difficult to achieve. That is where transparency, prioritization, and visibility of organizational objectives to all teams are useful.
12.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Inspecting and adapting at regular intervals is necessary to re-enforce good practices and make improvements. Agile encourages teams to practice self-sustained introspection and retrospectives. This is an important tool for program teams to review and use to fine-tune their practices for long-term success.


Agile principles, though exhibiting an overlay of software development influences, can be valuable for managing programs involving multiple teams from diverse functional groups.