Trust: Your Agile Sub-Flooring

by Rebecca Stevenson

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.

Do You Want to Play a Game?

by Brenda Camille Davis

Nine 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.

I 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.

On 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 Game”.

As 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.  

During 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

No matter what game you are playing, if it is promoting the Agile principles, ceremonies, or continuous learning, then this a part of being Agile.

Being Agile – have a Balanced View!

by Gayathri Daggubati, Agile Coach

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 destination.

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.

Agile on, my friends!

Cheers,

Gayathri

The Risky Business of Arbitrary Deadlines

By Sheila Eckert

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 stress.

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 time.

COMPLETE THIS PROJECT BY NOVEMBER 30TH.

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 traffic.

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 begin.


RISK AHEAD

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 Accident?

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.


STRESS

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.

Introduction to Kanban

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 improvement.

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 money. 

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:

  • Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.

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 instantly visible.

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.

The simplest Kanban board.

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 this weekend. 

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 waiting).

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 terms.

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:

How much of your work can you see?

And this is what an online board with sixty things to do looks like:

How about now?

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 digital boards.

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 Scrum does.”

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 news.

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.

Book Recommendations

Kanban in Action

Personal Kanban

Making Work Visible

Unplanned Work During a Sprint

by Sheila Eckert

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 do it.

Often the practice is to deal with it and not make any changes to the sprint backlog.

THIS IS A MISTAKE.

You need to create a new sprint backlog item. It needs to be estimated and added to the sprint.

Not doing so will throw off metrics.

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.

Unplanned work needs accounting.

The One Where I Accidentally Presented At a Conference

By Zoë Kaler

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 all?

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 THEM!  

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.

Alignment Across Product Teams

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 and marketing.  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.