And now for something unrelated only tangentially related to the ongoing crisis. This has been loitering in draft for a while, and I’d like to get it out there for feedback.
We spend a lot of time talking about tools and techniques related to specific Agile methods — how to do a good retrospective, or prioritize a backlog. Today I want to talk about something that is a necessary ingredient in any Agile implementation, no matter what set of practices you’re putting into place. That ingredient is trust.
How many of us have heard and seen one or more of these:
We’re not allowed to talk to the customers directly.
We would like to let the teams self-organize, but we just don’t think they’re “there” yet.
We need to get sign-off from upper management before we experiment.
I just keep my head down and do my work.
We need to make sure everyone on the team has an assignment.
I could go on, but I think we’re all familiar with these or similar symptoms. To me, these are indicators that most people in an organization think that trust is a “nice to have.” If they see a problem arise, for them it lies in the system, in the overt actions that people are performing — people aren’t being held accountable, people aren’t following through, we’re not keeping on top of them. They’re not thinking about the invisible substrate, like the old idea of phlogiston, that enables and hinders communication.
Let’s think about this through the lens of Scrum, since even those of us who don’t practice it or don’t like it are familiar with it.
Trust has to begin with oneself; personal integrity is another piece of the subflooring. You need a certain degree of trust in your own perceptions, self-awareness, and honesty in order to communicate trustingly with other people. If you’re not able to be honest with yourself, nothing in the Agile stack is going to work for you.
Backlog refinement? “Eh, I can knock that out in a day. Two at most.” Standup? “I don’t need any help with what I’m working on.” Retrospective? “That thing that happened was my fault; I should just keep my mouth shut.”
Move it up a level; what happens when the team members don’t trust one another? Collaboration suffers. Standups are a chorus of “I” with never a “we” to be seen. “Will they follow through? Better just do it myself.” “If I say I don’t know something, am I going to get made fun of? Or worse?” “If I ask for help, will they take all the credit?” “The last time I proposed we try something everybody just ignored it. I won’t do that again.”
Instead of a group all pulling together toward an agreed-upon goal, you have people who may or may not be moving in the same direction, and whose priority is self-defense. That is, first, a waste of energy. People only have so much of it, and self-defense eats a lot. Second, it means that the entire point of having people work in teams has been missed. Learning, creative gestalt, emotional support, the possibility for innovation–these things are emergent properties of people working in a group, and they emerge only when communication occurs freely.
Finally, when happens without trust between the team and the organization as a whole? When teams aren’t trusted to make their own decisions, to plan their own work, to know their own minds–when the organization isn’t trusted to communicate truthfully, to set priorities clearly, to act respectfully toward the people who comprise it–you have left the realm of Agile practice entirely. Processes have triumphed over people, planning over adaptability, fear over delivery.
In the future we’ll talk about building blocks of trust — what are its components, and how you can build them up.
In the meantime, what do you think?
Rebecca is a technical writer and Agile enthusiast working in the Boston area.
years ago in the Windy City, at one of the major financial corporations, senior
leadership decided we need to make a major change. The business stakeholders
were not pleased with the time it took for a project to be delivered to them,
which usually ranged from nine to eighteen months. The decision and intentional
commitment to begin the Agile transformation came from the top. A leading Agile
transformation company was hired, and training and coaches were in place.
was a project manager at the time, with over ten years of waterfall mindset,
when my Agile journey started. I was a sponge and open to learning how our
teams could make improvements. To start the process, I registered for class and
began googling information on Agile, but there was so much information, I
decided to wait for class to get started.
day one of class, leadership kicked off the day with “Why Agile?” The senior
vice-president talked enthusiastically about the Agile benefits. A surprise to
me, we were told to pair up with someone at our table and to write on post-it
notes, “Why do we have difficulty delivering projects in a timely manner?” We
were told to put our post-notes on the white board under the category that they
best fit in. A few of us said, “I think we are playing a game.” It was never
called this by the coach, but it was “The Learning the 12 Agile Manifesto Principles
my Agile journey continued, I loved the improvements I saw with the teams I
worked on, and looked for opportunities to learn more about the framework and
what other companies were doing that were having successful transformations. I
joined local Agile meet-ups and attended meetings and conferences that were
focused on Agile.
one of the local meet-up group meetings, we were broken into teams and told that
for the next five minutes, we should write on post-it notes and add to the
board what we do each morning before we leave home to go to work. We were then told
to name the tasks we would perform if we only had 15 minutes after waking up
and before we had to leave home to go to work, so we worked with our team to
eliminate some of the tasks from the board. In the next iteration we only had 10
minutes, then five minutes. Through this game, we learned team building,
prioritization, and introducing Kanban to share with our company teams. The
Kanban board should all the tasks in the “To Do” initially, then in the 15
minute column, then the 5 minute column; this was our way of showing how WIP
(Work in Progress) looks on a Kanban board.
More recently, as a SAFe Scrum Master, at the end of each iteration I facilitate the retrospective with my team. It is important to keep the team innovative, engaged, motivated and encouraged to grow and share. Each iteration we play a game, and yes, there are post-it notes. These retrospective games have included Weather (What were the weather conditions of this iteration?), Your Super Power (What Super Power Did You Demonstrate During This Iteration?), Focus On/Focus Off (productive communication), and Twitter (In 140 words or less write about the iteration). The team says all the time how now they look forward to attending Retrospectives because they are all new and each one challenges their way of thinking of improving and growing as a team. These games and so many others are found in the book Agile Retrospectives Making Good Teams Great by Esther Derby and Diana Larsen and by Googling “retrospective”; there is a great list (40 ideas to spice up your retrospective) on www.agilestrides.com.
matter what game you are playing, if it is promoting the Agile principles,
ceremonies, or continuous learning, then this a part of being Agile.
Agile is not something you do; Agile is
something you are.… “Be Agile.” This phrasing is quite popular, and I’m sure
you have heard this before.
But have you ever wondered what it takes
to “Be Agile”? If so, this short read is for you.
There are two “equal” aspects that contribute to the state of being Agile – one is the methods and frameworks that Agile offers, and another is the mindset that Agile promotes.
I quoted “equal” because there are still individuals, teams, and organizations who are focusing more on the former aspect, the “practices and processes” that the chosen Agile framework prescribes, and are losing the sight of the latter, the ”values and principles” that actually lead to an Agile growth mindset.
The reasons for this imbalanced view may
vary, but what happens when you ignore the values and principles?
Let’s pick a practice — daily huddle, sprint
planning, or sprint retrospective. They all introduce an immediate change in
your current ways of working, and those who understand the purpose behind each
of these practices will see the long term benefits they offer. But what if you
are focusing only on the short-term gains? Like having a chance to communicate
the progress with your team in the daily huddles, having an opportunity to
raise your voice and express your concerns in the retrospectives, setting a
super powerful goal for your team in the sprint planning? While these short-term
benefits are not less important than the longer term ones, one must not forget
that these practices were designed in the first place to support the core
values and principles that the Agile inventors believed in and thought would
create long-term reliable success for the individuals, teams, customers, and the
organizations as a whole.
The real transformation begins when you
start mapping each of these practices back to the Agile values and principles.
That’s when the same daily huddle becomes more than just a chance to
communicate progress with your team, that’s when the retrospective becomes an
opportunity to discover your team members perspectives rather than raising your
own voice, and the sprint planning becomes an event where you as a team
estimate your chances of success instead of trying to set a goal that convinces
the customer or the management.
I’m curious, how many Agile practitioners are living the values and principles vs following the practices and processes alone, that any given Agile frameworks like Scrum, Kanban, Scrumban prescribes?
The Authors of Learning Agile, Andrew Stellman and Jennifer Greene, beautifully explain in their book how teams that try “going Agile” by adopting a lot of great practices end up by having ”Just Better-Than-Not-Doing-It Results”. Teams just following practices with an incompatible mindset may still see improvements immediately (the short-term gains I was referring to above), but will certainly fail to realize the true essence of being Agile. In my view, these results would be very similar to the results that a confidence without clarity produces, which can become a disaster!
On the other hand, without practices, principles
are sterile. Think of what happens when you have an Agile compatible mindset
already, but don’t have a work environment that encourages suitable practices,
one that supports and complements your mindset? There is struggle, there is
frustration, less job satisfaction, you name it!
Thus, from an individual to an
organization, a continuous and consistent effort has to be made in order to
maintain a balanced view towards Agile practices and principles.
I usually compare this balanced view with how one aspires to balance their physical and mental health – the two aspects you would consider to “be healthy”. What happens when you only focus on physical fitness, but not mental health? Self-explanatory, isn’t it!
Staying principled and adhering to the
values by aligning your thoughts, behaviors and actions towards those
principles helps to strive and thrive in an Agile environment. And just like
being healthy is a continuous journey, being agile is also a journey, BUT not a
SO WHAT YOU DO TO SELF-REMIND, AND HELP
MAINTAIN THAT BALANCED VIEW TO ‘BE AGILE’?
Refer to agilemanifesto.org to see the 4 core values and 12 principles of Agile. Please note, each framework (ex: Scrum, Kanban and Scrumban) has its own set of values and principles that one must adhere to.
The Merriam-Webster definition of
Arbitrary: ‘based on or determined by individual preference or convenience
rather than by necessity or the intrinsic
nature of something’.
This is not about ‘True Deadlines’
like adhering to a new FDA regulation, implementing code for new tax laws,
needing software completed before the start of the school year. Managing true
deadlines is a story for another day.
While True Deadlines do exist, often
deadlines are an arbitrary date.
While it is good to have goals,
target dates and milestones, an arbitrary deadline created to pressure teams to
complete work by a given time is fraught with many unnecessary risks and undue
To illustrate, we will look at two
scenarios, a developer who has been told that she must complete a task by a
specific date and a motorist who is trying to get to his friends house by a set
COMPLETE THIS PROJECT BY NOVEMBER
ARRIVE AT FRIEND’S HOUSE BY 2PM.
So, both our subjects have tasks
with deadlines assigned.
All goes well at first. Moving along
on the road. Coding is going great.
Our motorist is stuck in bad
Our developer has come across a
piece of the requirement which is more difficult than anticipated.
Both worry about the looming
deadline and determine that if they don’t do something, they will not meet
their goal. THE DEADLINE HAS BECOME THE GOAL. And this is where the RISKS
The two are looking to shortcuts
so the ‘deadline goal’ can possibly be met. They have lost sight of
their actual goal.
Our motorist decides to try a
‘shortcut’ around the traffic but the road he needs is closed. He is now
mindlessly following his GPS, hoping it is going to make up the lost time.
The developer starts to look at
shortcuts, at cutting corners. She will try to create a less than ideal
solution. It should work but we need to forego good coding practices. She is
unsure if this solution will scale but there is no time to worry about that
now. She introduces technical debt. She limits the amount of testing.
The goal has now gone from result
oriented to deadline oriented. Based on how far behind we are, there is a need
to speed up further.
Our motorist begins to speed and use
dangerous rather than safe driving practices. More risk. Speeding ticket? Car
Time to code fast, not smart. More
risk. Less than ideal solutions. Details missed. Technical Debt. Bugs.
In the end neither of them finishes
on time. Risks were introduced and results less than ideal.
Fines to be paid. Repairs to be
done. Insurance cost increased.
Bugs to be fixed. Code that needs
rework. Features eliminated. High Latency.
Throughout the process both
experienced unnecessary stress. They did not meet the deadline. The
result is not what was expected and much less than perfect.
The GOAL is to ACHIEVE
the DESIRED RESULT as quickly as possible.
Arbitrary deadlines do much more
harm than good. Use meaningful but looser targets — dates and milestones. Do
frequent assessment and necessary adjustments. Code smart, not fast. Limit
technical debt. Build in quality.
Following this approach results in quicker
delivery of the desired outcome.
Many organizations get interested in Kanban due to its
lightweight methodology when compared to other Agile practices. Often, however,
they aren’t sure what Kanban actually is beyond a To Do/Doing/Done
column layout, and something to do with cars. So what is it? What does it
offer? And how do you use it?
What Is Kanban?
There are lots of things you can read about where Kanban came
from; the short form is that it’s a method pioneered by the Toyota car
manufacturing company, with roots going back to the 1940s. Kanban (and you can
pronounce the “a” long or short) is a “lean” workflow management system that
emphasizes waste reduction through just-in-time processes and continuous
According to Toyota, there are six rules for Kanban (per Wikipedia). The first three rules are:
Each process issues requests to its suppliers when it consumes its supplies.
Each process produces according to the quantity and sequence of incoming requests.
No items are made or transported without a request.
What these rules amount to is the definition of a pull-based system. Each person working in a process takes on more work as the person doing it has capacity, not as the work becomes available to be done. If you have thirty tasks on your To Do stack, you don’t add any more until you’ve gotten rid of some of the existing ones.
The result of this process in an ideal world is a system in
which nothing happens until a customer places an order, upon which the system
requests materials and produces exactly one perfect car instantly, because
having materials sitting around unused and cars sitting around unsold both cost
The software industry, lot of magpies that we are, took this
idea and said “what if we could approach software development like that?”
Because having half-finished software sitting around also costs money.
Back to the rules.
The request associated with an item is always attached to it.
Processes must not send out defective items, to ensure that the finished products will be defect-free.
These are about quality; every step is traceable, and every
product is as close to defect-free as possible. Sending out sloppy product is
at best wasteful – you will inevitably spend more resources addressing the
problem than it would have required to fix it at the time it occurred – and
potentially ruinous for an organization. Doing work that you can’t track back
to any particular need is similarly wasteful. I’m sure most of us have had the
experience of looking back at the past week or month and trying to figure out
what we spent all of that time doing. If we can’t answer that question, though,
how can we hope to figure out whether we should do things the same way next
month, or if there might be a better way to use the time?
The final rule is this:
the number of pending requests makes the process more sensitive and reveals
The final rule describes work-in-progress (WIP) limits. The
best, simplest demonstration of how limiting WIP speeds up flow is through the
penny-flipping game. https://www.tastycupcakes.org/2013/05/the-penny-game/
The tighter the focus of the work, the faster work moves
through the process—and the more quickly the team will become aware of problems
with that process. When you only work on one thing at a time, delays are
The route to putting these rules into practice is the Kanban board.
The simplest form of Kanban board is one you’ve probably seen
around: three columns labeled To Do / Doing / Done.
This is probably fine if you’re keeping track of personal
tasks; unless you’re a serious productivity geek, you just want to know that
you made a dentist appointment and need to pick up flowers before the party
Regardless of scope, every board starts with a backlog. Where
do tasks come from? How do you decide what gets top priority? What counts as
work? Not knowing (or not admitting) how much work you actually have and where
it all comes from makes the system less useful.
So one of the first things you’ll want to do is to write up
all of the tasks, one card apiece, and put them on the backlog in some kind of
order. When it comes to writing a task card, less is more, at least to start
with. You don’t want to have repeated “what was that about again?”
conversations, but you don’t need to include every detail on the physical card,
either. Put enough on it that it’s useful to your team.
Once you’ve got a backlog, create columns for every state
your tasks occupy from start to finish. Don’t be tempted to discount things as
“not really work”; that stuff adds up, and you end up wondering why everything
takes so long. Are things waiting for more information, being reviewed before
they go out the door, or being researched? Are there dependencies outside the
team’s control? Make them visible.
It is critical to have clear, transparent rules spelling out how work moves from one column to another. This is part of your Kanban commitment to quality. It’s easy for unacknowledged work to hide in those transition areas.
Once you have the columns figured out, you can add richness
to your board. It should be visible at glance who on the team is doing what.
You might do this with different colors, or with stickers on the cards, etc. You might also want to include dates [MOU1] (when it came in, when it’s due if there is
a hard deadline), and how long the has spent in various stages. You don’t have
to restrict yourself to words here, either (one story I read involved a team
who stapled a banana peel to a card to make it obvious how long it had been
Once you’ve got a solid sketch of the workflow, go ahead and start using it. Don’t be afraid to make changes if they’re needed down the road. One of the great things about Kanban is the lens it provides through which to inspect your work. If your model of how things get done doesn’t turn out to match how your team is really doing things , then change the model.
A Few Important Terms
In this section we’ll define some useful Kanban-related
Lead Time – Lead time is the period between a new task’s appearance in your workflow and its final departure from the system. (source)
Opinions vary on whether you should start counting from the moment something hits the backlog, or the moment someone commits to working on it. Personally, I think there’s more value in the former, because that’s information. If new tasks spend forever in the queue, why is that? If something has been in there for months and never reached the top of the priority list, are you really going to do it?
Cycle Time –Basically, the time it actually spends being worked on. Cycle time begins at the moment when the new arrival enters “in progress” stage and somebody is actually working on it. (source)
Work in Progress/WIP – The number of work items in a given column at a given time. A “WIP limit” is a hard cap on how many things can be placed in that column, ever. (Remember, Kanban is pull-based! You don’t take a new task until you finish something you’ve already got.) More work in progress leads to longer cycle times. When you consider how much time is lost to context-switching, it doesn’t take very many things to be in progress before you’re spending more time moving among things than you are moving any one task forward.
Swimlane – A horizontal pass across the Kanban board that allows you to describe different workflows for different types of work. Lots of places have a “fast lane” for customer-critical issues (but when everything is a critical issue, beware).
What Makes Kanban Useful?
First, it’s easy to tell what’s going on in your team from a
well-populated Kanban board. No one should ever have to attend a status meeting
ever again. Personally, that alone would sell me on it.
This, by the way, I find to be a strong argument in favor of using a physical representation of your work instead of an online one. Because this is what an online board with six things to do looks like:
And this is what an online board with sixty things to do looks like:
Being able to see the whole thing at once really does make a
difference to your brain. What you have to scroll to see, you will not pay as
much attention to. Online boards miss out on entire dimensions of information,
literally. Don’t just assume that there’s no other way you can do it, either; I
would at least urge that people experiment with analog before resorting to
The second benefit to Kanban is that you can do experiments. Now that you’ve got your board all put together and once you’ve been using it for a little while, you have a lot of data. With that data in hand, you can try different things and see what happens—where do things slow down or speed up, what effect does it have if you change WIP limits, what if people cross-train… you’ll find endless opportunities.
You can do these things just as easily with your personal board as you can with a work board for a big team, when you have all of the information visible. Just remember that if you think a good goal is “everybody is busy 100% of the time,” it’s easy to make that happen: just jack WIP limits through the roof… and watch the team’s throughput dive.
Where Can Kanban Go Wrong?
At risk of taking a detour here, one of the reasons I hear
people decide to move to Kanban is “it doesn’t have all of those meetings like
Hm. Okay. Let’s go with that for a moment.
What are the Scrum ceremonies? Backlog refinement, sprint planning, daily standup, sprint review, and retrospective. What happens at each of those meetings? You agree on which are the most important tasks, the team plans which of them they’re going to do and how in the next iteration, the team plans out the day’s collaboration, the team reviews the iteration with the customer to adjust plans for the next one, and the team collaborates on potential improvements.
Maybe you don’t need to do those things in a formal meeting,
maybe you don’t need to do them every week or two or three, but I would argue
that if you stop doing any of those things altogether, you are cruising
for misery no matter what Agile toolkit you’re using. And if your motive for
adopting Kanban is you don’t like working collaboratively, I have some bad
One of the other places where Kanban goes sour is when people
stop keeping track of the data their board provides to them. The board can provide
you with a lot of information. Cycle time, lead time, and the visible movement
of work through the flow can identify bottlenecks, dependencies, and places
where the overall work can be improved. If you’re not using the information that
comes out of the system, you might as well not bother with the system at all.
Finally, the most important part of any Agile cycle is the
inspect-and-adapt loop. What happens if you change the WIP limit? What happens
if you automate a step? If you cross-train a team member? If you start taking
on different kinds of work? If you’re not doing that loop – inspecting how you
work and trying things to make the work better – then you’re missing at least
half of what makes any Agile [MOU2] toolkit useful.
We’ve all been there. “Hey, can you help me with this issue I am having?” “Can you run a quick report?” A critical production bug needs to be addressed. You are asked to attend one or more unplanned meetings.
You need to
practice is to deal with it and not make any changes to the sprint backlog.
THIS IS A
You need to
create a new sprint backlog item. It needs to be estimated and added to the
so will throw off metrics.
matter. Productivity metrics, project metrics, quality metrics, Agile health
metrics. Metrics are used for the team’s own measurement and improvements. They
are used to measure the effectiveness of the Agile process as well as the
teams. They are used for reporting to stakeholders. They are needed.
If you have work unaccounted for during the sprint, you have thrown this out whack. That’s the technical term for your data is invalid 😊.
If you are
using invalid data, you are creating invalid, useless metric reports.
Last September, I attended my first work conference: Agile Midwest
2019. Day one was called “Women in Agile.”
The keynote speaker was an upbeat, knowledge-filled woman named
Jenny Tarwater. Her interactive keynote included a worksheet to help us create
an action plan for “Amplifying Our Voices.” There was a section on the
worksheet called “I Will…” where we listed the things we, as women in agile,
will do to amplify our voices. The first thing I wrote was “embrace the
uncomfortable.” Little did I know how soon I would practice this pledge.
Day two of Agile Midwest 2019 was called “Open Space.” Again, first
work conference, so I had NO idea what that meant; I came to find out it
essentially means crowdsourcing the day’s topics. All 350ish of us sat facing
the middle of the room where the microphone and “stickies” were. If you
had a topic you’d like discussed, you came to the middle, wrote it on a sticky
and announced it to the room. Then you put the stickie on panels called the
“Marketplace,” which indicated the time and room number for that topic.
In the morning session, I sat back and watched. I didn’t think I
had anything to contribute to this group of seasoned conference-goes. However,
when we reconvened for the afternoon, I knew I wanted to contribute. I saw a
gap in the morning sessions. There was so much talk about how to do Agile, how
to implement Agile, problems with Agile, but no talk about what happens after the product development parts of Agile.
What do you do after you created this awesome product? How are you telling your
users and stakeholders what you’ve accomplished? Are you even doing this at
I’ve found stories to be an effective way to talk about these product
outcomes, so I added, “Storytelling in Agile” to the Marketplace. I
chose the first time slot for the afternoon session, so after the Marketplace
was full, the conference-goers disassembled to their selected topics and I
headed to mine.
1pm arrived. It was time to get started. Trying to start a
conversation, I asked the room if they wanted to share how they practice
storytelling in Agile. No one raised their hands. Someone piped up and said,
“Aren’t YOU going to tell US??” My throat lumped up and I realized that
these people were not here to have an open conversation. They were here to
learn about something they knew nothing about, and they expect ME to teach
I brought this topic to the Marketplace because it’s something I
believe in. I studied storytelling in undergrad as a journalism major and in
grad school as an information science student. I’ve gone on to practice it in
my career. I know a thing or two about it, but, needless to say, I was not
prepared to teach these people anything. I began to recall all I could from the
IS 590: Storytelling course I took in the Fall 2018 semester. So, there I was,
rambling about the story structure of “The Three Little Pigs”. I asked
questions and got no hands, asked more questions and got blank stares. I felt
the lump in my throat grow, my neck and face get hot, and my chest tighten.
What the heck was I doing?!
Luckily, I had just been to a session called, “Everything
Icebreakers,” so I decided to break the ice with a game called “Link Up.” The
object of the game is to learn something about everyone in the room while
forming a human “link.” The first person yells out something unique about them,
such as “I have a cat!” and if you have a cat, you yell, “link up” and run up
the that person and link arms. This goes on until everyone is “linked.” I saw
this as an opportunity to not just breaking ice, but for me to prepare for the
next 50 minutes.
With the broken ice and then next 50 minutes roughly planned, I
dove in, embracing the uncomfortable…
I told a story about the jacket I was wearing, how I’m trying to
pay off my student loans at an accelerated pace, and how the trip to Ann Taylor
LOFT to pick up said jacket set me back a little more than intended. That got a
few laughs and boosted my confidence. I told them about the three main elements
of a story: tale, teller, and audience. I asked them to tell their neighbor a
story; then we talked about how they felt telling and listening. We talked
about empathy and how we’re humans who remember narratives better than facts.
Then we talked about “Three Little Pigs” (again) and “Little Red Riding Hood”
and how those story structures can apply to the corporate world.
This 60 minutes in conference room 103 at Agile Midwest Open Space
was the scariest thing; standing up there, responsible for filling the heads of
theses 20 or so individuals with knowledge.
But it ended up being a huge growth opportunity.
As I was looking over my notes from Agile Midwest 2019, that note I
wrote under the “I Will…” section caught my eye. In fact, a ton on the notes I
took at “Women in Agile” caught my eye. I’ve even signed up for their
“Launching New Voices” program to improve my public speaking skills.
I could’ve left the room, I could’ve ignored my urge to add to the
Marketplace in the first place, but I felt a little fire that day that told me
to keep going and stand in that uncomfortable place.
This introductory post kicks off a new series on how to improve alignment among teams within an organization, and is linked here by permission of the author. Read Alignment Across Product Teams on Learning to Be!
About the author: Dev Gupta, MBA, PMP, CSM, ACC — After spending a few years implementing enterprise software with SAP, Dev Gupta realized that software automation and process redesign reach full benefits when executed by people who are performing at their peak capabilities. Programs that seek efficiency, innovation, cost savings and improved quality are dependent on a foundation of team members who are open to change, cultures, communication styles and personalities.
Through her work at global corporations, Dev has
collaborated with colleagues and clients in Germany, UK, India, Japan,
Romania, Australia, China, and Canada.
She appreciates learning about different cultures and finding the common thread in people.
This lead Dev to complete her coaching certification and draw upon change management methods.
Her experience centers on process work, project management,
software implementation for a variety of industries, like high-tech,
medical devices, pharma, and consumer products.
Dev has a BS in Computer Science from Rivier
College and an MBA from Babson, where she focused on entrepreneurship
She achieved her Project Management Professional certification
(PMP) in 2012, completed her International Coach Federation (ICF)
training in 2018 and became a certified Scrum Master (CSM) in 2019.