SolutionsIQ-Agile Enterprise Solutions - Scaling Agile for Organizations
At SolutionsIQ, we know Scaling Agile is possible: we have Agile Enterprise Solutions that make the best Agile tools and practices work for your business. Follow this blog to get Agile Coaching,Agile Software Development,Agile Transformation, Business Agility and much more.
Over the last few years, we have seen a transition happening across Agile delivery teams. Where coaching used to be something you exclusively get from the outside of the organization, it is now crucial for organizations to develop an internal capacity to support, grow and sustain greater agility. And yet there are still many organizations still struggling with the idea of needing team coaches. Why is this? This only scratches the surface: I’ve heard other really good questions that make the need for strong coaching at nearly every enterprise client of mine, including:
How is it that there are so many ScrumMasters out there who are unprepared for their role on a team?
What does a coach look like if you are leveraging Kanban?
If ScrumMasters also have coaching the team as a responsibility, why would you even need a team coach?
In this article I want to demonstrate the need for both ScrumMasters and Agile team coaches and also how SMs can start on the path to becoming outstanding coaches.
Entry Point into Agile – ScrumMastery
It is a sad fact that most ScrumMasters have done little more than take a certification class to earn their role. Indeed, Scrum Alliance’s Certified ScrumMaster course is the basic entry point for all new agilists, because it introduces how Scrum (and Agile to a lesser extent) works, what the role of the ScrumMaster is, and how to facilitate the Scrum ceremonies and use the Scrum artifacts. This course – certified or not – is a great primer for what Scrum is and how that releases trapped value of delivery teams. It also reveals some of the Agile mindset to people who typically don’t know much about Agile. While these are all important and great, three points are worth mentioning here:
Agile is more than just Scrum. Scrum is only one of frameworks for breaking complex work into easy-to-consume tasks. Kanban and Scrumban (a Scrum-Kanban hybrid) are other options.
As I mentioned above, simply getting your CSM certification isn’t enough to be an effective ScrumMaster. What this introductory course doesn’t do—and cannot do in just two days—is reveal all of the things ScrumMasters have to do to foster truly high-performing teams. The ScrumMaster role, done right, is much more than just scheduling meetings and updating a burndown chart.
While coaching the team is a responsibility of the ScrumMaster, the extent of this tends to be limited just to their team(s). Agile team coaches can have deeper and broader impact on several teams, because their primary focus is making great teams out of good ones, facilitating the Scrum ceremonies and removing impediments.
The ScrumMaster role has become misunderstood over time, changing many times into an Agile project manager role, or essentially a meeting creator/facilitator role that anybody on the team can do. This is very different from the servant leadership role that Ken Schwaber intended. This misconception causes ScrumMasters to feel that their role is undervalued and not appreciated. Many ScrumMasters I come in contact with over the years feel they have very little respect from their teams or from people outside their teams. They feel the teams understand Scrum and are going through the ceremonies, but they aren’t getting better. These ScrumMasters don’t feel like they have the authority to address most impediments or challenges beyond the team.
I have collaborated with other coaches to discuss with ScrumMasters about their current role and what they want to make of it. We coaches point out how the role of ScrumMaster shouldn’t be about walking the team through a series of ceremonies but of helping the team get to a high-performing state, where the team can truly learn how to self-organize and adapt. We explain how an empowered, fully trained ScrumMaster truly can be a model and change agent for transforming the larger organization. We also point out that it takes a lot more to be an Agile team coach than to be a ScrumMaster.
Evolving to Agile Team Coach
When I started as an Agile coach in 2007, there were fewer people who claimed to be Agile coaches. In those days, an Agile coach was usually focused on helping an organization adopt or scale Agile practices across and beyond teams. These Agile coaches were to become the initial change agents/champions to bring about organizational change, primarily by helping create other change agents. As I grew into the role, I started working with larger organizations, helping them through any dysfunction and creating/modeling an environment where response to change and creating value were easier and faster. I began to focus my Agile coaching on the mindset of overall organizational agility rather than any specific Agile framework or tool, like Scrum or Kanban.
But then I noticed something: many ScrumMasters were adding “Agile Coach” to their titles. While some of them had every right to do so, my experience was that it was merely a résumé change without any personal development. As more people started to add the job title of Agile coach in their organization, I started to worry. Is a person whose role is to facilitate team meetings really coaching the team? Do these new “Agile coaches” really know how to coach, let alone how to coach well? What skills have they learned and developed beyond basic training?
The role of the Agile coach is an important one requiring integrity and hard work. I am personally excited that Accenture | SolutionsIQ is the sole provider of Agile Coaching Institute (ACI) coaching training, Coaching Agile Teams and The Agile Facilitator (which we also offer together as the Agile Coach Bootcamp). When you consider the depth and breadth of the material offered in these classes, you start to get a more complete picture of the skills you need to be an effective Agile Coach. The ACI’s competency model divides up the Agile Coach role into several competencies beyond the basic experience of a Lean-Agile practitioner, namely: Facilitation, Mentoring, Professional Coaching and Training. There are also specializations to explore: Technical Mastery, Business Mastery and Transformation Mastery. Accenture | SolutionsIQ is so committed to this coaching training that it is part of our core requirements for all of our Agile coaches – none of this adding “Agile Coach” to your résumé without putting in the actual work.
Agile Coaching Competency Model (Source: ACI)
You may think it’s time to stop using the title of ScrumMaster, and perhaps just call them team coaches. In fact, if you aren’t using Scrum, having a ScrumMaster on your staff won’t make sense. But if your organization is or is striving to be Agile, then Agile coaching invariably has value.
Changing the name of the ScrumMaster role to team coach does little to move the needle in terms of your Agile teams’ high performance. Any winning team has a successful coach behind them. And any great coach knows that success comes from continually learning, developing skills, and getting help from mentors. Perhaps reframing to a coach role will get us to the promise of Agile getting to high-performing teams. Either way, the goal is not to simply have roles like ScrumMaster and Agile coach; the goal is to achieve high performance. Agile coaching is the most effective way to unlock high performance in Agile teams.
Or so the coaches of the some of the best Agile teams tell me.
Read the original post here in our Learning Library.
Experienced Agilists will recognize this anti-pattern immediately. It will look something like this:
Teams will make a very ambitious plan either quite close to or even exceeding capacity because work had not been completed last iteration.
Teams will not manage risk or create contingency for unexpected demand or other interruptions due to delivery pressure.
Teams will execute an iteration and not complete their committed stories to varying levels of “doneness.”
Teams will push work to the next iteration and go back to step one.
This pattern, which has its basis in over-commitment, practically ensures that actually committed work is never completed without extending work hours. Work continually leaks into the next iteration, which causes over-commitment to the following iteration, ad infinitum. I have named this the “Wraparound” anti-pattern, and is one of the more recognizable anti-patterns that appear in transforming and maturing teams. It also notably occurs in scaled enterprises at all levels.
The primary effects of the Wraparound are these:
Team increments of business value (user stories) cannot be completed within an operational iteration. This makes planning awkward and unconvincing and dissipates team energy.
Team commitments come under doubt after multiple iterations where commitments were not complete and can disrupt trust within and among teams.
Flow of value through operational teams become “start-stop-start-stop” instead of continuous because the capability for QA to pull work is not possible because of what ends up being team overload.
Abilities for teams to pivot and re-plan are hampered when cycle times of story development are too long to get work done within the planned increment. This problem is exacerbated by waterfall artifacts such as “approvals” and “reviews” appearing in the work flow.
Longer-term estimation of larger value increments become increasingly error-prone.
“The more detailed we made our plans, the longer our cycle times became.”
— Donald G. Reinertsen, “The Principles of Product Development Flow”
How does Wraparound Emerge?
One of the trickier notions of agility is learning a good sense of how much work can be done. Who is best to determine this? Usually it is the team, but teams that are newly minted or going through additional translation or just emerging from training are usually not comfortable enough with their own capabilities to predict the amount of work they can accomplish with any level of accuracy.
1 – Underestimation, immaturity
Part of this equation is determining how much work a team can take on legitimately. Regrettably (and fortunately), there is hardly enough space in a single blog post to cover such a rich and complex subject such as estimating, which has so many techniques as well as so many proponents or detractors that it will detract from the core of this post. Suffice to say, underestimating is exceptionally common, given the perception of teams that they are always “under the gun” to produce more and more value with less time and cost.
When teams underestimate work, they have difficulty mapping the work into a plan because the probability that a team can conceive of a way of getting their work done becomes harder as the iteration rolls on. All of a sudden, tasks that we expected would take hours seem to take days, and end up on disappointed on demo days and scrambling to re-work completion strategies on planning days.
Underestimation also comes from failure to account for “handoffs” and other inefficiencies within a development value stream. The knack of leaning out a value stream is to identify internal processes that hamper completing tasks and eliminating them. Although we all agree that fully cross-functional teams are ideal, these rarely exist. The best we can hope for is to focus on minimizing the amount of time spent not delivering value.
2 – Teams not protected from late demand or rapid priority changes
Although the fundamental tenet of agility is to embrace and welcome change, it is very difficult for the formula of “reciprocal commitment” to be operable on a team force. Although change is welcomed, it is better off to have strong ScrumMasters and other operation personnel protecting a team’s committed plan. The temptation for external forces to influence the behavior of a team in flight is very tempting, and we must strike a balance between continuity and predictability.
If teams spend much effort planning, all while continually deflecting additional demand, enough time and energy can be sapped from a team to cause disruption in value delivery. Agile leaders MUST understand the difference between “EMERGENT” and “URGENT” and only disrupt teams when emergent conditions or matters of sufficient urgency to cause a team to have to re-plan in flight occur.
If leaders get into a habit of changing priorities or business value in flight, teams will never be comfortable enough to settle into good patterns and improve their performance dramatically.
“[…] If your goal is to deliver a valuable product to a customer within some targeted boundaries, when change and deadlines are significant factors, then reliable Agile processes work better.”
― Jim Highsmith, Agile Project Management: Creating Innovative Products
3 – Too rigorous definition of “Ready”
In order to engage stories for planning, they must be in a state where they are complete enough to plan with some degree of accuracy. We are expected to use the INVEST mnemonic to show us where a value story is in its journey to be engaged as work. Frequently these definitions become far too large to be pragmatic, and delay the ability to estimate and plan work. Here are some examples of “readiness” that are contrary to the spirit of leanness and agility:
“Story content and estimate must be agreed upon by all members of the team” – Not so. It is a fallacy that there must be agreement by all members of a team about every aspect of every story. The Product Owner’s responsibility is to decide the truth about business value, not the team.
“Acceptance Criteria need 100% understanding” – Also not theoretically possible. Scientific studies have shown that we can achieve somewhere in the 75%-80% range of understanding, and that efforts to achieve more than that detract from ability to do work efficiently.
“Performance Criteria are defined” – This might be true for overall performance levels of an application, but if the functionality is only understood at 75%-80%, how can the performance be understood any better?
“Stories must cover a vertical slice of a full deployment stack” – This is a common misconception about the breadth of user functionality in a thick stack. It is simply infeasible to built discrete separate units of executable functionality across an entire stack during the short time of a team iteration. This needs to be re-interpreted and re-discovered by teams. It is far more efficient to build sub-slices of a full stack and verify them independently than try to build unit and integration tests for a full-stack dive into business functionality.
“All applicable test cases must be identified” – Another impossible hurdle due to the uncertainty of user story business value. These should become clear as the story is engaged by the team.
“All dependencies must be identified” – We do try to think as far ahead as we can to foresee dependencies, but – again – until we are fully engaged in a story, we cannot know with certainty that all dependencies are identified.
Generally speaking, a story should be considered ready if two things are true:
The Product Owner believes the truth about the story to be MOSTLY correct, to the best of their knowledge at the time.
The team agrees that the story can be completed in some iteration based on their understanding of the Product Owner’s communication of value.
The INVEST mnemonic insures that both of these are true, and serves in itself as a good guideline for a workable “definition of ready.”
4 – Too ponderous definition of “Done”
As with the definition of “Ready,” this definition can prove elusive. To succeed as an Agile team, we must focus on rigorous quality, but balance this with time-to-market and predictability. Many organizations have definitions that are too meticulous and prevent value from being completed and moved along the value stream to integration and deployment.
The true definition of “Done” is rather simple: was the customer/consumer’s need satisfied? We use the Product Owner as a high-availability proxy to answer this question on behalf of the customer/consumer.
Here are some examples of “doneness” that seem also to be contrary to the spirit of Agile:
“Code has to be reviewed” – In the age of XP development practices, it is hard to believe that we still have this appearing in definitions. The obvious way to eliminate this is to take advantage of pair programming and mentoring, which provides a sort of continuous review of code being woven into team operations. Given the proven techniques of test-driven/behavior-driven development, automated testing and continuous integration, this step becomes a bottleneck.
“Documentation [X] needs to be produced” – Refer to the first value of the Agile Manifesto. Working code should be the source of truth for how a system functions.
“Unit tests pass” – This should not be included for teams that have embraced CI/CD as it is redundant. If teams are not in CI/CD, TDD and BDD lose much of their value.
“Story approved by UX/UI or Architecture” – This should be done as part of the story definition, not as an approval process after the work has been completed. This sets up an additional potential bottleneck to getting stories across the Kanban within an iteration and adds unnecessary dependencies on workers outside the team proper.
“Refactoring Completed” – This is very nebulous and speaks to the same issues as code reviews. Refactoring is a technical technique that should be in continuous practice, so the idea that it is “completed” is paradoxical.
“Compatibility Passed” – This usually refers to integration of code developed by teams and should be brought out by automated regression testing. Imagine having to test your code manually against every compatible version of code? Yuck! Compatibility is an integration, not a development issue.
5 – Understaffed Teams
Although we hate to bring it up, the Wraparound can be a sign that the development teams are taking on more work than they can produce or more complex work than they can produce in a given period of time. If teams always feel that they are under the gun, when a real emergency happens, there may be no reserve of team energy to tap into. Once we start making teams work more than a reasonable work week, productivity goes down immediately. Management should take a serious and continuous look at teams and their structure and look for these issues, which can lead to deficiencies in value stream delivery.
Also, and perhaps more insidiously, there are insufficient cross-functional skills within organizations to get work done within an execution team context. If teams are over-staffed with developers and analysts, we can expect the ability to drive through QA to be significantly hampered. This is why the ideal team is not divided into execution roles and should be able to do any tasks that are needed to get a story fully complete and ready to integrate.
How Do We Fix the Wraparound?
It is not possible to understand every team’s context and composition, but here are some steps an organization might undertake to eliminate this phenomenon without putting the brakes on development and re-tooling the value stream:
Slow down and catch up – We don’t want to stop the train, but if we are behind, there is something to be said for reducing capacity dramatically until teams can get out of the Wraparound phenomena. Reduce capacity until your teams are succeeding, then increase as they mature.
Review development value stream and reorganize – Use value stream mapping on a small scale to uncover all of the steps that work has to take to get out the door. Identify obvious bottlenecks and correct them! Eliminate approvals and reviews wherever possible!
Staff teams properly – Make sure your teams have enough talent, skills and time to do the work that is expected of them. If not – FIX IT. We should not be afraid to re-align teams that are nor organized for maximal efficiency. Add headcount or reduce workload!
Narrow definitions of “ready” and “done” – If your team is struggling with getting work onto, across or off the Kanban, think about simplifying these definitions. Sometimes they include unreasonable requirements that slow delivery and do not add value or assure quality.
Keep your work small – Smaller work items move across a Kanban more quickly, contain fewer tests and test cases, have fewer integration points and have smaller regression scope.
Eliminate WIP limits – WIP limits exist to speed work up. If your WIP limits are slowing you down, you are not using them correctly. Eliminate them until you can ensure they are helping and not hurting your team.
Agile is still a new way of looking at the world, and even though it is being slowly embraced, we still have a long way to go before its principles and values are fully integrated into our value-producing cultures. By identifying anti-patterns like this, teams can put themselves on a legitimate path to improvement and emerging as high-performing value creators.
The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes. ― Kent Beck
With our recent webinar on Agile product management as an enabler of product innovation, we wanted to dispel some common misconceptions about innovation. Resident innovator-consultant Jeff Steinberg outlined for us his ideas and shared his experiences with product innovation in a past Agile Amped podcast called “Creating Disruptive Innovation Inside the Enterprise.” In this episode Steinberg identifies eight misconceptions keeping many organizations from innovating at the pace of change.
Creating Disruptive Innovation Inside the Enterprise with Jeff Steinberg - SoundCloud (2585 secs long, 181 plays)Play in SoundCloud
1. There’s only one kind of innovation.
There’s two types of innovation, at least two types… One is sustaining innovation. These are the things that are built on top of our existing business. It is the new features that we create, it is the new market that we expand into. It is the things that help us to continue thriving with today’s business model…
Disruptive innovations are really the things that will create tomorrow’s new business, a new customer… If companies want longevity, and want to be on that S&P 500 list for many years, you’re going to have to reinvent yourself. Sometimes it even means disrupting yourself.
2. You can cram innovation into an existing industrial-age process with things like SAFe’s “Innovation and Planning sprint” and see results.
[Factory worker management is] designed to kill innovation. It’s designed for a known business model, for a known customer, and to repeat that. You certainly won’t get any innovation out of that. It’s not what it’s there for…
SAFe has become very popular… In SAFe, there’s actually something called the innovation and planning sprint. For me, it’s just insufficient. It is structured as one sprint, typically at the end of a quarter, and it’s certainly not dedicated to innovation. It’s in the title, but it’s this thing that gets sandwiched between – unfortunately, often times – hardening of the current work, or research… and planning for the next program increment. They squish all these things together and somehow expect innovation to come out of that. I think in those innovation sprints, it’s rare that [it] even happens.
3. Hackathons lead to disruptive innovations.
I love hackathons, I’m a big fan of it, but unfortunately it’s a single fixed point in time. It’s also one of those things that happens quarterly at best, and it happens for often times two days. You hear about the “ship it” days, or FedEx days, whatever it is, and it’s fun. People, they form teams on their own and they stay up all night, and they rock something out, and it’s a fantastic exercise, but it is just that.
I think it’s a creative outlet at best, and unfortunately the ideas that go into those hackathons are either on their way in, pitched, or on their way out, approved by … You can really think of it as the internal venture capital, the managers. That’s where it gets approved by, and that’s not the customer. I rarely see that working.
4. And so do innovation labs.
Then, we’ve got innovation labs. This has been another popular one. I’m guessing a lot of our enterprise listeners have some form of an innovation lab that is like some myth inside the company that the black-turtleneck people get to go into, and they come up with great ideas…
These innovation labs are designed to do one thing: to come up with innovative ideas. They’re not designed to also create new business models out of those ideas. They come up with an idea, and it gets handed off back into product development to go and execute on it. And, unfortunately, you get a lot of these “not in my backyard” syndrome, or the motivation just isn’t there. The people that it gets handed off to to build the real business out of – [it] gets handed to a product manager, and they say, “Oh well, okay. Here’s a new idea. I’ll just put this at the bottom of my very, very, very long backlog.”
Nothing comes to fruition out of that. It usually gets killed.
5. You can hire in an “innovation expert” to solve your problem.
The last one that I unfortunately see is the strategy of, “Let’s hire the expert. Let’s hire somebody from outside the company, the CEO or the CIO.” Or, “Let’s pay a lot of money to get somebody who can help, who will know somehow, I don’t know how, what tomorrow’s disruptive innovation will be.” I think that’s misled also.
6. It’s enough to have internal people – VPs, managers, executives – telling us our innovative ideas are “business viable.”
Steve Blank gives us a great phrase…: “Get out of the building. There are no facts inside of these walls.”
We have to be experimenting with potential customers, with the users, with our friends, or with the closest thing to really the early adopters as we can. What we’re going for is data-driven learning. That may be qualitative data, which you’ll often get from customer interviews, before we’ve even done an MVP. Or, it may be very quantitative data, so if you have qualitative data, go for quant. If you have quantitative, go for qual. We need to be surrounded by data, that’s where the most learning comes from, because it’s not enough to just have your opinions. We actually want to be testing behavior of people who’d be interacting with these products.
7. Innovations and learning are generally applicable, because they aren’t context-specific.
I worked for a company a number of years ago that, this was a startup, this is one of those big success startup stories. They were doing marketing in the legal space. So, how do attorneys get new business? It was basically lead generation, and they got very good at that. I mean, they were, like, printing money. Leads, they could charge a lot for ’em, the lawyers needed ’em, it was fantastic. I think we got a big head and thought, “Well, if this business model works here, it should work in any industry.” We attempted to apply that to real estate. This was before the real estate industry tanked, this is about a decade ago. I was a project manager at the time, and I was a very good project manager. I took this grand vision of our internal visionary leader, and turned it into a product, and I built a thick book of specifications that had every detail outlined in it. That took me a couple of months, and I handed it off to a design team, and they made it look pretty, and they handed it off to developers, and they spent several months developing it. Finally, they handed it off to the testing group, and – classic waterfall story.
But when we finally launched, we were very excited, only to find that nobody used it. The leads were too expensive, and the business model was just wrong… We did not need to spend a year and all that investment to learn that. We could have created some simple MVPs to test that. For me, that was a very painful experience.
8. Innovation is something that only startups can do.
We often hear of innovative startups becoming big corporations – but what about big corporations who need to innovate but have a lot more overhead? Steinberg offers:
“We need a balanced innovation portfolio management approach. There’s this concept of managing three different innovation horizons. There’s Horizon One, these are the things we’re currently doing that are working well. We have Horizon Two: tomorrow’s extension of our existing business model, an extension of our products. This is where a lot of that sustaining innovation fits in. But then we have innovation or Horizon Three. In horizon three, this is where we’re managing for disruptive innovation. We need to allocate resources to each of them, and often times I’ll hear suggestions of, say, 80% in Horizon One, and 15% in Horizon Two, and 5% in Horizon Three. I think that’s what they were saying several years ago. I would actually increase those numbers. It’s probably 10 or 15% today in Horizon Three, and 10 or 15% in Horizon Two, because the world’s changing at a more rapid rate. We need to invest more if we want to stay relevant and we want to continue to disrupt…
I got a lot of inspiration from Scott Cook, the CEO of Intuit, and that’s a company that clearly has been very successful with innovations and reinventing themselves. There’s this quote from him that I absolutely love: “You can fool yourself into thinking that you can reform the hierarchy.” Essentially, you’re just fooling yourself, and the hierarchy may be very necessary for scaling, and managing that Horizon One. And possibly for Horizon Two, also. But the hierarchy is designed to control, and that’s where trying to use that in Horizon Three goes wrong.
This article was a collaborative effort by George Schlitz, Ryan Keawekane, and Adam Asch.
In this 2015 article Tom Goodwin wrote:
“Uber, the world’s largest taxi company, owns no vehicles. Facebook, the world’s most popular media owner, creates no content. Alibaba, the most valuable retailer, has no inventory. And Airbnb, the world’s largest accommodation provider, owns no real estate. Something interesting is happening.”
What has happened is that many traditional businesses have been disrupted by startups who have placed one thing above all else: customer delight.
Previously, customers were a necessary evil in the money-making engine. But today a confluence of technological, political, social and business advancements has amplified the voice of the consumer, wrestling power away from mega-corporations and redistributing it among those businesses that have acutely attuned their focus on solving real customer problems, not simply delivering widgets. The enterprise primed to survive and thrive in today’s environment, guided by a clear vision and human-centric values, has all four of the business agility capabilities:
In our upcoming webinar, “Enabling Product Innovation Through Agile Product Management,” we paint a picture of how innovation is possible with an evolved, Agile approach to product management. If business agility is the driving force enabling companies to thrive at the pace of change, then Agile product management must be its engine.
Learn How Agile Product Management Fuels Product Innovation
In this webinar, the fourth installation of the Business Agility Webinar Series, George Schlitz and Adam Asch connects the dots between product management in Agile organizations and product innovation, a capability necessary for business agility.
Here are 7 things you need to know about Agile Product Management.
1. Agile product management is lightweight, continuous, smaller in terms of effort, and less linear.
The era of building big, long-term strategies designed upfront, both for business models and product lines, is behind us. Agile has enabled businesses to accelerate their value delivery to the market – but often at the expense of product strategy. The reason for this is that, led by a widely pervasive and mistaken view that Agile is only about delivering software and a desire to get on the “Agile train,” businesses failed to determine the role of strategy, longer-term planning, and customer research in an Agile organization. Agile was being used to create prioritized backlogs for delivering value – often in the form of widgets or features that may or may not have been what customers need most – and most were happy just to deliver something on time and within budget.
Today we recognize the weakness in lacking product strategy and customer understanding: customers don’t care about more features. They care about solving their problems – and Agile product management restores an organization’s capability to determine what customers need and what market opportunities might exist or need to be created. Agile product management, among other things, ensures that product backlogs represent our best learning about customer needs and desires, while helping realize successes hypothesized by Agile product managers.
2. Agile product management depends on a constantly evolving strategy.
To the layperson, Agile processes seem to lack strategy, because they focus on constantly looking for small increments of value to deliver, and only those with insider business knowledge are clear on how these slices of value deliver against more strategic goals. In fact, strategy is even more important in Agile processes, and in particular product management, because the work is continually growing, shifting, and evolving in starts and stops. The Agile organization is obsessed with things like customer delight and competitor disruption because these are on opposite sides of the same problem: unhappy, underserved customers constitute an orchard of opportunities ripe for creating market disruption.
One thing the Agile organization is not obsessed with is getting it right the first time. The premise that any business can get it right the first time is flawed and reveals an anti-failure, linear-analysis, overconfident mindset that enables the more flexibly and curious mindset to easily to upset and disrupt it.
3. Agile product management shifts the focus from output to outcome with an intent to have impact.
We love to measure things, even things that are essentially meaningless. One common measure is output: how much stuff we have delivered. Saying, “We delivered this much stuff in this much time” seems like a far better measure of success than none. In a production system, more units moved may equate to greater success.
With increased uncertainty and volatility, however, these types of metrics can be misleading. In Agile product management, we evolve away from measuring output towards measuring outcomes. Where output tracks units, outcomes track the result of the consumption of a particular unit. A smoothie stand may produce lots of smoothies, but only those that lead to a purchase, and then satisfied customer count as an outcome. This opens the door to deeper if less linear customer impact (e.g., more return customers, more customers in general due to word of mouth). Creating impactful customer experiences is the new “it” metric – so much so that Adobe has built an entire platform around it.
4. Agile product management aims to turn data into insights.
People like to point to data as a good thing in itself (especially in this time of “big data”), but lots of data can quickly turn into lots of confusion. Agile product management is focused on drawing insights from data; making sense of the numbers, words, and experiences; identifying trends, underserved segments, and opportunities for competitor disruption; and more. Insights, not data, yields learning. If data is the words on the page, insights are story the words tell, the sense we are able to make of it.
Through processes like Design Thinking and Lean Startup, Agile product management aims to make sense of data – i.e., generate insights – faster and thus to learn. Research and experimentation are need-to-haves. The new “it” business analysis capability is how to use more data without getting bogged down in it.
5. Agile product management leverages Design Thinking to analyze customer problems, find market opportunities, and examine viable solutions.
Disruptive innovation can be scary to companies who have figured out how to establish a healthy revenue stream. While this fear is understandable, embroiled within it is the mistaken assumption is that the problem is that it’s impossible to do everything on top of watching out for disruption. Instead businesses should unravel their reliance on antiquated business mindsets and processes – annual budget cycles, internal innovation chained to the parent company’s business model – and get comfortable with uncertainty, change and continuously striving to delight customers. The idea is to re-align business objectives to customer needs and wants. But how do you do that effectively?
Design Thinking is a methodology for creative problem solving that individuals and organizations can use to tune into customer problems and examining solutions to these problems. Where, at the team level, Agile prescribes that Product Owners create and prioritize a product backlog, Design Thinking has powerful tools to better do so. Where Agile experts might stare at a blank user story template, Design Thinking helps them arrive at a compelling story and “so that” statement.
6. Agile product management is all about the MLP (Minimum Lovable Product).
It’s not enough to have a working widget anymore: customers have to love your product and develop loyalty to your brand. The MVP (minimum viable product) and even the user story were both intended to get at this problem, but have acquired baggage that results in teams delivering lackluster features quickly, or delaying customer delivery because “minimum” must include everything the old product or competitive product does. Or worse: they may call whatever is finished by the end of a sprint the MVP.
Increasingly, we are focused on concepts like MLP – the minimum lovable product. What is the least you can do to generate a good, strong feeling in your user? How do you get the wow factor out of a widget that results in real customer outcomes? One easy answer is: test it on actual customers.
7. Agile product management is an innovation enabler.
In the HBR article “What is Disruptive Innovation?” we find sound advice for enterprises:
“Incumbent companies should not overreact to disruption by dismantling a still-profitable business. Instead they should strengthen relationships with core customers while also creating a new division focused on the growth opportunities that arise from the disruption.”
This statement encapsulates the need for Agile product management both for near- and long-term business reasons:
Innovation (potentially both disruptive and sustaining) should be a part of your strategy, not your entire strategy.
Maintaining happy customers is as important as seeking out new markets (and customers) to delight.
Businesses disrupt themselves when delighting one customer base interferes with the delighting of another customer base that the business is servicing.
From a business agility perspective, Agile Product Management is key to figuring out WHAT to deliver (Product Innovation), HOW to deliver it (Delivery Agility) and WHY it matters (Vision, Strategy and Goals). Without Agile Product Management, it doesn’t matter what you innovate – it is likely to have all of the same problems as your current products. Further, innovation doesn’t happen in a vacuum but can be fueled by data-driven insights and guided by desired impact on underserved markets. Agile Product Management enables you to put it all together and derive the hoped-for value.
Register Now for the Next Business Agility Webinar!
Wednesday, June 13
10 AM Pacific (1 PM Eastern)
In this webinar, the fourth installation of the Business Agility Webinar Series, George Schlitz and Adam Asch connects the dots between product management in Agile organizations and product innovation, a capability necessary for business agility. Through compelling stories with enterprise clients, they will cover the key aspects of Agile Product Management and how each differs from their traditional counterparts. They will also provide actionable ways you can assess how your organization’s existing product management is hindering or helping your business agility.
Once again, the Women in Agile session packed the house, this time at the Keep Austin Agile conference in Austin, Texas. Around 120 women and men gathered around for the purpose of building a network where love and connectivity flourish, and the community collectively supports and inspires other women working in the Agile field.
The movement is beginning to gain momentum: After sessions at Agile 2017 and SAFe Summit 2017, more Women in Agile chapters are beginning to crop up around the country. New York City, Atlanta and the Bay Area have already established chapters, and more are on the horizon. According Deema Dajani, one of the organizers of the Austin event, Women in Agile is in the process of becoming a non-profit organization with more resources in the future to support this growing network of agilists.
Finding Personal Sustainable Pace
The topic at hand was timely and resonated with the audience after a long week of work, family obligations (and lack of family time), volunteering, travel and in many cases more than one conference. Tamara Nation led the crowd through a session on finding personal sustainable pace and discovering where to fit in the world physically, mentally and spiritually.
Nation opened up about her own personal struggle with compromising her health over work. She drew an analogy to work as a relationship, in which work was a horrible, unforgiving partner. About eight years ago, she began feeling abused and woke up to the realization that work was taking a toll on her health, leaving her forty pounds overweight and miserable.
She reminded us that work should be a good thing. Besides allowing for money and resources we need, it gives us a sense of identity and personal achievement. It offers social contacts and support and provides structure for our lives, as well as mental and physical stimulation. However, Nation pointed out that while most of us offer kindness, generosity and care to others, we often forget to offer it to ourselves. And that is when not only our wellbeing suffers, but so does the quality of our work output.
Impact of Burnout
There is a wealth of scientific evidence supporting the fact that stress and burnout have a tremendous impact on both our body and mind. In an article for the Association for Psychological Science, Alexandra Michel writes:
“Many of the symptoms of burnout overlap with the hallmarks of depression, including extreme fatigue, loss of passion, and intensifying cynicism and negativity. At its core, burnout emerges when the demands of a job outstrip a person’s ability to cope with the stress. Ultimately, burnout results when the balance of deadlines, demands, working hours, and other stressors outstrips rewards, recognition, and relaxation.”
The article goes on to describe how prolonged stress literally changes the structure of our brain, as well as affects cognitive functioning “disrupting creativity, problem solving, and working memory.” As if that weren’t enough, chronic stress leads to higher cortisol levels, which in turn cause coronary heart disease leading to 370,000 deaths annually in the U.S. alone.
Additionally, as Nation experienced, chronic stress can also lead to the dreaded “muffin top” or a “beer belly”. According to an article from the National Institutes of Health, studies have shown an association between uncontrollable stress and abdominal fat distribution.
Nation asked us to take out our phones and select a photo that represented something about us, and to share the meaning behind it with the rest of the table. Without fail, every picture and story that was shared told a story about time for ourselves, or time with our families and friends.
One woman shared that she wakes up at 4am every morning and quilts for an hour to spend quality time by herself. Another shared a picture of her at the playground in work clothes, while her children and husband were dressed in jeans and a t-shirt. Yet, she found the time to be with her family. I showed a picture of me on a mountain top in Boulder, Colorado where I had just visited two days prior after couple of hectic 12-hour work days at Mile High Agile, and still managed to find the opportunity to connect with nature and my coworkers. And my favorite of all of them was a young mom of three boys who shared a picture of her with her baby strapped on her back, while carrying another child walking into the woods.
“An unexamined life is not worth living.”
Personal Meter Reading
Nation invited us to do a “personal meter reading” to figure out why we were feeling the way we were. And the only way to do that, she said, is to pause and reflect. She then guided the room through a meditation, which is one way to figure out what is really happening within ourselves. When she asked us to share what shape we were in, the answers weren’t that varied: tired, frazzled, anxious…
Somehow we have forgotten that we bring our whole selves into the workplace, and don’t often stop to consider the sacrifices we’re making for the sake of efficiency. “It’s about balance and boundaries” said Nation, offering techniques that have worked for her:
• Be outside every day.
• Don’t look at your phone first thing in the morning.
• Don’t work and eat at the same time.
• Take breaks during the workday.
• Spend time with friends.
• Do a daily prayer practice.
• Avoid activities that deplete you more (booze, TV, chocolate).
• Take a true day of rest, not just time off work to run errands.
• Use all your vacation time.
To close, Nation invited us to take an active role in defining our own relationship with work and in finding our own personal sustainable pace. Finally, she encouraged us to make a connection with other Women in Agile in your local area, whether that is a meetup, group or an event. To find more information and support, visit http://womeninagile.com/.
Listen to the Agile Amped podcast episode with Nation recorded at Keep Austin Agile 2018:
Leaning into Sustainable Pace with Women in Agile - SoundCloud (1674 secs long, 23 plays)Play in SoundCloud
Let us count the ways that we love May: one great Agile community, two inspiring regional events, and more than a dozen new Agile Amped podcasts! We are humbled by and proud of the impactful change that this community is making in big and small ways. A huge thank you to the event coordinators that made Mile High Agile and Keep Austin Agile such great successes, bringing together hundreds of agilists – coaches, consultants, enthusiasts, learners – to co-create and share experiences and knowledge. These events serve to remind us of the power of the Agile community. That strength is needed more than ever as more companies undergo Agile transformation. The people of this community act as guides for millions around the world who don’t always understand what is so good about Agile. But this community knows, and that’s why Accenture | SolutionsIQ continues to be excited to sponsor these events!
If you couldn’t make it to Denver or Austin or simply want more reason to love being an agilist, enjoy this selection of our favorite podcasts.
Teams of Heroic Learners with Diana Larsen
Teams of Heroic Learners | Diana Larsen - SoundCloud (2076 secs long, 32 plays)Play in SoundCloud
Diana Larsen is the Chief Relationship Builder at the Agile Fluency Project and she has a simple compelling message: software development is learning work. Knowledge work is what everyone is talking about – but Larsen argues that learning is really what we need to be doing today. She talks about “heroic learners” – people who have the courage, compassion and confidence to learn everywhere and all the time, because as Larsen puts it, “We have to get good at learning – or we get left behind.” And this goes beyond just individuals – she discusses how teams need to learn together.
4 Steps to Change with the ITC Map
4 Steps to Change with the ITC Map - SoundCloud (1776 secs long, 28 plays)Play in SoundCloud
Drawing from the work of Lisa Lahey and Robert Kegan, Henry Dittmer shares his experience using the Immunity to Change (ITC) map to help participants of his session identify what is keeping them from achieving a desired change. Dittmer used the four-step ITC map to demonstrate why – paradoxically – he doesn’t like presenting at conferences. The four steps are:
What One Big Thing do you want to commit to changing?
What are you doing or not doing that’s keeping you from doing this thing?
What worries and fears (hidden competing commitments) arise when you think about doing this thing?
What assumptions make these commitments real for you?
Outcome Over Output – Don’t Be a Backlog Lumberjack
Outcome Over Output - Don't Be a Backlog Lumberjack - SoundCloud (2099 secs long, 12 plays)Play in SoundCloud
Kalpesh Shah is an Enterprise Agile Coach and self-proclaimed Culture Hacker at IntraEdge Agile Solutions, and his experience has demonstrated that, despite the widespread adoption of Agile frameworks, many teams are simply going through the motions like “backlog lumberjacks” who chop up their story/logs without no concern for what happens before or after their part in the value stream. Shah admits that when asks these questions and hears the answers (e.g., “Stories come from JIRA”; “The Product Owner consults the oracle”; “Production support happens”), “I died a little inside… These teams have been Agile for a while!” But the problem is pervasive and indicative that many organizations are using Agile without being Agile. Shah offers advice for helping teams and indeed the larger organization to connect with users and get more of the value of Agile.
Avoiding the Product Death Cycle
Avoiding the Product Death Cycle - SoundCloud (1673 secs long, 18 plays)Play in SoundCloud
At Keep Austin Agile 2018, Leon Sabarsky found himself in one of the worst time slots: the last presenter of the day, the only thing standing between attendees and Happy Hour. To counter this, Sabarsky decided to mix things up, donning a Grim Reaper outfit and wielding a scythe, which works well for his session topic “Avoiding the Product Death Cycle.” Sabarsky defines the product death cycle for us and offers sound advice for how not to wind up in it, including:
For app devs, find out how not to be one of the thousands of apps that are downloaded and deleted.
For product business and startups, come up with lots of ideas – don’t just fall in love with one because, chances are, it won’t succeed.
Avoid the “Next Feature” fallacy.
If you haven’t yet subscribed to Agile Amped, do it now – that way you’ll get all of the great podcasts that we have lined up for you right to your inbox. Our fans are awesome and we look forward to seeing them everywhere we go.
Below is an amalgamation of answers by both Brent Barton and Mike De Luca.
In our last webinar “Organizational Adaptability Through Active Executive Sponsorship” – the third installation in our Business Agility Webinar Series – SolutionsIQ’s Brent Barton and Beyond Budgeting Round Table North America’s Mike De Luca focused on a typical mistake that executives do in their Agile transformation initiatives: delegating the entire change initiative rather than actively engaging in and supporting the process. The discussion raised to several interesting questions including a few that we couldn’t cover, which are answered here.
1. Ranata asked, “Say you are entering an organization that has started Agile transformation but the PMO organization is still operating in a traditional PMO role. Are there specific suggestions on where you might start to change how that PMO works?”
There are two types of PMO’s, in my opinion: tactical and strategic. A tactical PMO essentially acts as a housing for project managers, and it runs in a very tactical fashion. It’s very difficult for a tactical PMO to change an organization at a grass-roots level because their job is by definition not strategic: They are given a budget, scope and schedule, which they’re trying to manage and over which they don’t have a lot of power. The ideal here would be elevate the tactical PMO to be more strategic, to integrate more strategy into the work it does and how it does that work. It means inviting in the people that are making strategy decisions and changing the entire conversation. Unfortunately, the PMO manager may perceive this as a career-advancing move more than an organization-enhancing move, and this may be a risk for the organization to consider.
In contrast, the strategic PMO tends to have a lot of representation from business, if it’s in an IT environment. So, conversations around prioritization and portfolio naturally arise. Thus, we have the opportunity to engage them, along with their financial counterparts, to really help shift the conversation. In the webinar, Mike De Luca gave an example of a large business doing away with the traditional budget, and in this context we have the opportunity to shift the strategy and bring together key stakeholders:
The demand representation, who are concerned about what we should be going after, what should shift, which things should stay the course, and which we should walk away from
The capacity representation, who are the teams and their actual capacity to deliver and the manner of that delivery
The strategic PMO, which represents the people in portfolio management along with the people that operate those endeavors within that portfolio
Because all of this goes beyond the PMO, you need an executive transformation team. You need to be able to change the stories because changes will not survive without the CFO, the business leaders and the CEO coming to agreement and supporting the transformation.
2. Jeffrey inspired the following question: “How do you adapt executive compensation to enable organizational adaptability? Doesn’t the organizational alignment required to do away with traditional budgeting, for example, challenge the justification for the current compensation structure?”
Considering that the lifetime of an executive has gotten so short, executive compensation favors short-term gains over long-term organizational health. Many organizations are learning how to not succumb to the next quarter’s results but also pull back with a clearer perspective so that we can moderate and actually invest in the future and create stability. Executive compensation structures need to take that long horizon into consideration. Here are some ideas that we’ve heard:
If an executive is going to introduce a change, then they are required to live in that role long enough to see the outcomes and their bonuses are based on those outcomes, not based on changes themselves.
Consider market growth. Many executives simply reap the economic growth of our current market, which is coming out of a very difficult recessionary period into this slow growth. Therefore, executive bonuses often have nothing or very little to do with their real value-add.
Principle 8: Targets – Set directional, ambitious and relative goals; avoid fixed and cascaded targets.
This means that goals need to reach further out than the traditional annual boundary (“If you hit this year’s budget or sales growth number, you get a bonus”) and they need to be relative, taking into consideration organizational capability as well as the market environment. Businesses need to move away from short-term focus and fixed targets, like sales numbers and even budgets.
Principle 12: Rewards – Reward shared success over competition; not against fixed performance contracts.
Although there’s no single answer for how a rewards structure looks and behaves (it has to align with your organizational, your industry, and your culture), there are two points here worth making:
Rewards should move away from financial incentives. As De Luca says, “The dollar may be a near-term incentive but very quickly, it becomes an entitlement. And no additional effort is put out to get what is perceived as an entitlement.”
If you retain financial incentives, make them team-based or organization-wide. De Luca again: “If executives have the ability to be financially rewarded for organizational good performance, than everyone down to the front line should have the same opportunity.”
On this topic, De Luca offers his experience at Group Health as an idea of the possible:
“We did this in Group Health right away. We had management performance agreements, annual performance agreements, that said you will meet or do better than their targets. All of that language came out immediately. That was one of our first very tactical steps in implementing Beyond Budgeting. But then you have to think about what to replace it with… Beyond Budgeting doesn’t tell you there’s one way to solve this, this has to be really sensitive to both your market and your corporate culture. You’ll have some corporations where sales is a big part of the business model, where you may still have an individual incentive. You just have to think about how does that fit [with what the organization is trying to achieve]?
Most organizations that have moved away from the budget will do away with incentives entirely and move toward more of intrinsic motivation. Because now you’re organized around a common goal, and the engagement at the individual and the team level comes from achievement of outcomes… So some organizations will move away from financial rewards entirely and reward in different ways and move toward more of that culture of intrinsic motivation.
Other organizations, either as an interim step or more permanently, will move toward a team-based incentive. If this team or team of teams does x, achieves x as an outcome, then it could get this kind of reward. In Group Health, the entire organization had to hit certain outcomes, so it was disconnected, in some ways, to what I did personally as an executive director. But I still wanted the organization to be successful. And I knew that there was the possibility of some financial benefit at the end of the year, but it meant that everybody had to be focused on the organization being successful. And it wasn’t just around monetary outcomes: it was primarily around quality, customer satisfaction, access. It was around the things that mattered to our customers that we got measured on, on an ongoing basis.
It’s spring – and that means Agile Amped is heading out to connect with the community again at our annual May events. This year we are continuing to promote the voices and thought leadership of our experienced and insightful Agile community at a variety of events, some of which have grown in size and impact over the past few years. We are also humbled, grateful and excited that Agile Amped has surpassed 125,000 downloads on iTunes! That is huge, because it means that the reach of our collective voices is expanding beyond just the Agile and tech spheres. With the latest HBR issue headlining “Agile at Scale,” you can be sure that Agile transformation and business agility will continue to expand, providing even more opportunities for our interviewees and listeners to bring positive change to the world. With Agile Amped, we aim to remove time and distance as impediments from acquiring and even co-creating new knowledge concerning Agile. That’s surely part of the reason that Agile Amped is one of the top Agile podcasts on iTunes.
Podcast Highlight from Last Year’s Conference: Agile Team Metrics
Sanjiv Augustine is the president of Lithespeed and presenting at Keep Austin Agile 2017 on the five steps to creating hyper-performance teams (taking inspiration from Jeff Sutherland) and by extension disruptive innovation:
Standing teams – based from the concept of a standing pattern in complexity science
Agile Engineering – how do we get things to market quickly with high quality?
Lean Product Discovery – constant experimentation
Agile Budgeting and Funding – use our best intelligence to plan and build in flexibility
Innovation Pipeline Management – create new options, operate existing ones or trade out for new products
5 Steps to Disruptive Innovation with Sanjiv Augustine - SoundCloud (1808 secs long, 50 plays)Play in SoundCloud
Mile High Agile
May 21-22 – Denver, CO
The Mile High Agile conference hosts sessions that provide actionable guidance that you can immediately use on your own Agile journey.
Podcast Highlight from Last Year’s Conference: 5 Steps to Disruptive Innovation
Andy Cleff talks with us about his presentation at Mile High Agile 2017, “Agile Team Metrics – Measure Many Things” — an interactive discussion that explores how we can remove perverse incentives from our metrics and provide healthier ways for teams to gain meaningful insights on the outcomes of their experiments. Andy reminds us that “analysis without data is just an opinion.”
Agile Team Metrics with Andy Cleff - SoundCloud (1770 secs long, 95 plays)Play in SoundCloud
The momentum of business agility is building, and as it does there will be consequences and side effects. The values and principles of Agile should cause us to completely re-think the ways in which we look at the future of our organizations, and to be prepared to use these lessons to make substantial changes in the way we approach producing value. The greatest of all challenges is making certain that the principles and values we teach so enthusiastically to our development teams also take root in organizational leadership.
Decentralizing Problem Solving and Decision Making
One of the many conundrums we face is what I call the “Somebody Else’s Problem” anti-pattern. It frequently manifests as a leadership behavior when servant leaders at every operational level of an organization think Agility is for “other people” to do. For an Agile transformation to succeed, it must be a complete structural transition where knowledge workers and leadership work together to improve the efficiency of every aspect of value flow. There is no “somebody else” to lay blame on when transformation becomes dysfunctional. The essence of Agile is that collective ownership should be sufficient to give impetus to changing the way we think about “who owns the work.” The phrases “my code” and “my tests” are disappearing from our collective vocabulary, and “the work I manage” should be the next to go.
Agile is not a product – it is a framework of ideas, patterns and techniques to help organizations focus on maximizing value and quality. An Agile organization, therefore, is one where leadership allow the day-to-day decisions to be made by teams and individuals. Maximal value flow cannot be achieved when everyone is mired by the process of getting approval or asking for permission over and over again to do the work a team perceives as routine. After all, who knows best how to get the work done than the knowledge workers closest to the it? Management MUST learn to trust their teams. Management MUST learn to let go. If that does not happen, expect severe difficulties in any transformation.
“Letting go is the lesson. Letting go is always the lesson. Have you ever noticed how much of our agony is all tied up with craving and loss?”
― Susan Gordon Lydon, The Knitting Sutra: Craft as a Spiritual Practice
There is an inherent fundamental flaw built into many organizations – they are using the techniques and mentality that had been developed over the course of the Industrial Revolution in the 19th century. Organizations are still constructed as if they are performing simple, repetitive industrial manufacturing or service tasks. In the pre-computer world, efficiency was easy to scale since information and materials traveled relatively slowly. Now that technology changes so rapidly and volatility has become so impactful, as soon as we check in a line of code, its value seems to immediately begin to decay.
Management as Transformation Impediment
For an organization to transform, all involved parties need to be willing to change. In my experience as an enterprise Agile coach and consultant, the most common cause of transformation dysfunction is that management roles in an enterprise Agile organization are poorly defined and described. People who worked hard for years to attain positions of authority in an organization often have issues with the idea of “servant leadership.” Although a popular phrase to be certain, it does not seem to be embraced at all levels of enterprise Agility.
Fear of change and fear of failure are also important personal drivers. In many organizations, the watchwords are “This is how we always do it” or “This is how things are done here”. These sentiments are also due to cultural nostalgia as well as the sensation that people will be “judged” by the success or failure of the transformation. It is vitally important that management focus on the production of value and quality and not get too deep into the day-to-day activities of teams or over-focus on metrics.
Under New Management
Fortunately, there are many things that managers and leaders can do to create stewardship of an Agile organization so that it is in the hands of servant leaders rather than micro-managers:
Management MUST understand and commit to the principles of Agile, Lean, SAFe or whatever is pertinent to a degree that is compatible with expectations on their team force.
Commitment is a two-way street and is based on mutual trust, not fear or coercion.
Stop being a “boss” – let your knowledge workers do their thing. Teams cannot relax and create awesome work without autonomy, time and space to be reflective and innovative.
Don’t focus on process or command-and-control or insist on a sea of team metrics.
Treat your team members like they are real people with feelings. Do not refer to people as “resources.” Crude oil and coal, database servers and computers, are resources.
Provide an environment of cooperation and learning. Make sure teams are not pressured to work so hard that they miss out on important time for creative and team building activities, or family and personal activities. Do not create a culture where people are expected to work longer hours than is necessary; such a culture and organization are unsustainable long term.
Encourage and praise daring thinking, which may even be disruptive. Remember – your competitors are trying to think how to beat you at your own game. Creative solutions are one of the key elements in improving market position and staying ahead.
“Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them.”
― Paul Hawken
We must continually remind ourselves that there is no “us” and “them”; we are all in the same boat together. All organizations need management, but it is Agile leadership that makes an Agile organization efficient and enduring.
For several years, I was the managing director of SolutionsIQ operations in India. At times it was like I was always on a plane to or from Bangalore, where we have our office. I learned a lot more about the India market than I knew growing up there, and I met interesting people, not the least among them leaders looking for ways to drive change in their organizations.
Back in 2014, I had an interesting conversation over dinner with the CEO of a large office supply organization based out of United States. He had come on a ten-day trip to India to select an Indian offshore company to be his Agile provider for software development services. My conversation with him took place at the end his trip. And he looked visibly agitated! He had already met with many top software providers to learn about their ability to deliver high-quality software and demonstrate Agile software development capabilities. He was worried that the companies he met that week said “yes” to pretty much anything he asked. He was concerned that they were not being transparent with him. He ended up deciding to set up his development center in Chile.
Why did this CEO choose Chile over India? You could point at poor quality or that cost is generally the only motivator for setting up shop in India. I would argue that it comes down to a lack of foresight and leadership in the Indian organizations that this CEO was trying to build a working relationship with, which I can testify to myself. These companies typically have top-down and command-and-control approaches to running their business. The culture prohibits openness and transparency, even at the expense of decreased customer satisfaction.
Today my role is different, though I still serve as a leader. As I go about my day, I am reminded of a few experiences that happened to me and my team in India, because the same leadership obstacles affect organizations everywhere, not just in India. Since many leaders amongst us are going through transformation, I wanted to share five short tales of leadership from India, in hopes that other leaders can learn from them.
1. The Tale of the Vanishing Impediments
Every day at 11 AM the leaders of a large video technology company in Bangalore in what is called as a “management standup.” The group stands around an obstacle board like the one visualized here. The board is visibly displayed on the floor where delivery teams are working, so that everyone can see how, with collaboration and alignment, obstacles on the board vanish from the board.
It’s not magic: it’s Agile. Obstacles are automatically moved up from Manager, to Engineering Manager to Director depending on an SLA of how many days stale the impediment is. Each of the various leadership roles contribute toward resolving the impediments that are listed in their column. They also maintain an online organizational impediment backlog in Jira.
2. The Tale of the Super, Stable Team
In Magarpatta IT park in Pune, there is a super, stable team called ScrumMatrix. What is their super power, you ask? This team ships software weekly, builds embedded firmware products using a complex tech stack with multiple programming languages. Each of the team members is also highly capable of coding in any layer of the product, regardless of language or technology!
How is this possible, you may ask? Simple: their management decided, long ago, to leave the team as it is, rather than reassigning its members to another team when past products and projects were finished. The teams has been together for more than five years, which means they have tons of shared knowledge and excellent interpersonal rapport. And if there is a vacancy in the team, the other members decide who joins the team.
3. The Tale of the ScrumMaster who Annihilated Unnecessary Meetings
I have heard of a ScrumMaster at a healthcare company who worked hard and long and was able to do the impossible: remove unwanted meetings and interruptions for their team. As a result, the teams in this group do not attend any meetings except the Scrum ceremonies, and some design meetings. They all come to work at 9 and leave at 6. Their practice of core hours has removed the Lean waste caused by unplanned work. The team is overall very happy as they practice “If it’s not in the backlog, it does not exist.”
4. The Tale of the Curious Director
I know a leader of a world-renowned consulting firm. He works in Gurgaon. Although he is a Director for this company, he does not have an office for himself. He instead works with the teams in the team room. I have never seen him hold the center stage. He always has other members talk or lead in any meeting. If you ask him a question, he is likely to respond with another question. Instead of solving problems and telling people what to do, this leader strives to ask the right questions to trigger desired outcomes in teams. He understands the 300 people who report to him and thus uses positive questions to elicit positive responses, because experience has shown him that his people tend to react to questions according to how they are asked! He practices the policy I call “ask more, tell less.”
5. The Tale of the Team Who Worked Directly with the Customer
Finally, we have my director friend who, as a leader, encouraged his teams to work with global customers – directly. He was able to create a place where people are able to speak up openly and help each other. They feel safe that their boss will not get upset at them as he is always there to help them think through the problems. By working directly with their customers, these teams were better able to solve problems and deliver value. Although it was scary at times for some, including my friend, in the end it made more sense for their business for teams to collaborate directly with customers, rather than through layers of intermediators in a giant, and often frustrating, game of “telephone.”