Author Archives: Andre Castillo

Agile Reincarnated

I’m not an outpsoken guy. I don’t have any social media, other than YouTube or the occasional visit to LinkedIn. I never comment or post on YouTube, I just watch videos, and on LinkedIn I rarely comment. I guess that is to say that this is my only real outlet when it comes to all the chatter around Agile being dead. Which fine, lets say it was… THEN WHY ARE YOU STILL DOING IT!?

Sorry, I didn’t mean to yell. But come on. I go onto LinkedIn and all I see are posts about it. On YouTube the ever present algorithm knows what I like to watch, so I’m lambasted by videos about it. And so I ask myself… if Agile were dead, then how’s everyone delivering software? Did they all just up and decide to go back to a waterfall approach? LMFAO. I highly doubt that. There’s a reason that waterfall is limited to certain and or specific projects. No… more likely I expect that in it’s place, Agile has taken over.

Yep, you read that right. I’m guessing that what’s happening now is an industry wide recognition that there’s just too much “Agile” overhead in the form of guides and manuals and what nots, and not enough principles based engineering. Some of my first posts on this blog are about using the agile manifesto and ignoring Scrum and or Safe, and or all the other “guides” out there. Just follow the principles. And I think that’s actually what’s happening.

I don’t claim to be some Agile history guru, but if I recollect, the reason the agile manifesto was created in the first place was because some expereinced software people were tired of all the software project management overhead of the 80’s and 90’s and said… “There’s a better way to do this”. They got together and devised a document that, like it or not, has driven software development to where it is today. Yep, you read that right too. Most of the way you work today in software is in some way shape or form linked to that document. DevOps, CI/CD, Pair Programming, Mob Programming, Swarming, these are all related to principles based engineering and those principles are in the manifesto.

I’m not gonna lie, when I first started to learn about Agile, I was into Scrum. I dabbled. But even then I knew it wasn’t going to work. So we didn’t do it fully, we did some combination of it and Kanban. This was in 2013 (ish). I recall an auditor for a potential equity investor telling me that what we were doing then was called “ScrumBan”. I was like, ok, whatever. I called it “Better than Scrum”. I wasn’t some genius, I didn’t know the principles then like I do now (by memory), I just knew that if something isn’t working, don’t keep doing it.

I guess my point to all this is that I don’t think Agile is dead. I think the community of software people are just tired of the overhead. I think we’re coming to an inflection point where all that weight is being shed and what we’ll end up with is a new agile manifesto, or some derivative of it at least. It’ll probably be something like:

If it doesn’t work, change it. If people don’t like change, change the people. This is a deal breaker. Teams need to be able to change and do new things till you find a path. It’ll work well for a while and then things will change again. Life is change, software making is change. And yes, this does mean you should have retros with your team, and no that doesn’t mean they need to be therapy sessions, make them practical.
Deliver fast and frequently, do what you can to make sure it’s safe and doesn’t break too much. Keep in mind where you’re company is at in it’s maturity. No one will care if you got to 100% test coverage but you never found product market fit. Remember, you’re not constructing a concrete facility of some kind, you’re working with SOFTware. Concrete is concrete, software is not concrete. You can change it fast and easy.
People working on less things at the same time, helping each other and collaborating is better than more people working on a lot of different things and then tryign to tie it all together later. Stay focused and limit work in progress.
Don’t burn people out, people are people, give them space and time to live, but it’s also important that people recognize urgency and put in the extra time when it counts. Build sustainably and you’ll reap the benefits of keeping people and all their domain knowledge, and they’ll produce better results.
You don’t need only the smartest software people on the planet on your team unless you’re building rockets. There are plenty of smart and talented software people out there that can fit on any team. Do your dilligence but don’t be an ass.
The best way to know if something works is to put it into the hands of the people using it. Deliver these changes in small increments. Don’t spend time on a vision and then try to deliver on that vision without feedback. Ask people what they like and don’t like, survey them, collect user data. Do anything you can to understand what users do and don’t like about the changes your making. And again… MAKE SMALL CHANGES and deliver them frequently. If you aren’t making changes that make it to production or a production like system every day, you could probably be doing better.
Stop estimating as a regular practice, it doesn’t work and won’t ever really work well. Of course your team can give some “guesstimates”. Your team can tell you how complex they think something might be. But the moment you make a commitment to that, you’re doomed to failure (at least at some very high percentage of the time). Instead, if you follow the item above this one, you’ll be in a better position to validate changes as you make them. And as your team gets better at making smaller and smaller changes, the future changes will become more predictable (there’s lots of tools for forecasting, learn em, don’t stress your team out with unrealistic deadlines).
Trust the team you have, even if you don’t think it’s the best there could be. The chances are better than not that they’re are most certainly good enough to build whatever you need them to. And if not, they are what you have for now and not trusting them isn’t helping. If you have to, go ahead and provide some guard rails, but not a prison cell. And if the team needs too much guidance… you’re the problem not them, or at least, that’s your fault not theirs.

Yes, this is basically a derivative of the original manifesto, and to some degree a derivative of the DevOps principles which themselves were deratives of the agile manifesto. I don’t expect my off the cuff list above will become the next manifesto. Actually I don’t even think we really need one. I’m a purist when it comes to agile.

On my teams, I try to instill the agile manifesto and its principles in our environment and in the team so that those principles are how we operate. Yes, we have Kanban boards and tickets and process. These are just necessary elements of delivering software for some teams. We have flow metrics, and ticket counts and we sometimes provide guesses as to how long something might take. But as a manager, I manage leadership’s expectations more than I “manage” the team in some cases. I work to free the team up, give them space and time. In return they work with me to learn the principles and implement them, and that looks like the team making smaller and smaller changes, building tests and delivery pipelines, not overengineering things when less work is better. It’s a collaboration between all the members of the team, of which I’m just one. I see it as my job on the team to instill the right principles and then guide the team to find the practices that work best for that team and that follow those principles; I try not to impose any practice, though sometimes I have been known to impose, it’s a balance 🙂

Let’s be real. There’s no such thing as having no process. If you had no process, your process is having no process. And if you had no process, you’re probably a lone developer building your own projects. And even then, I bet you still have a process. No, I think when people say they hate agile or its dead or its dying, or that they are tired of all the “agile” overhead, what they mean is they’re tired of having systems imposed on them, and then having to try and work in that system, instead of having principles, and letting the system and processes form around those principles. And for each team those systems and processes might be a little different, but what won’t be are the principles.

Oh, but Andre, you’re not thinking about teams that need to scale. Is what everyone always says. Scale is just more people, your processes will have to change, but the principles don’t. If you stick to the agile principles and just let the teams form a system and process that include them, you’re going to find that all the so called rules set out in any number of different methodologies are all stupid. 2 pizza teams, 2 week sprints, scrum of scrums… who cares. Do you have a large team, so what if your delivering. Can you delivery daily, good, so why wait two weeks. Let all that shit go, focus on the principles and then see what comes out of it.

Is Agile dead, no. Maybe Scrum and Safe and whatever else is out there is, or will be. But no one’s going back to waterfall. I’d wager that if anyone did, we wouldn’t even know because they’d be out of business. They’d lose out to any competitors who are still agile. No, I think our industry is coming full circle back to the original principles, little by little, whether they know it or not. So, go on, keep writing catchy click baity articles about the death of agile… I expect I’ll still see those same article titles in 10 years.

The Poker Parable: Adapting Strategies for Success

Leave a reply

In a regular weekly poker game among familiar faces, there emerged an intriguing dynamic between two players, Al and Steve. Despite their long history and shared experiences, whenever they faced off in a hand, Al seemed to come out on top consistently. This pattern sparked a realization that transcends the poker table and offers a valuable life lesson.

Observing Al’s consistent victories over Steve led to a simple yet profound insight: there’s no magic or luck involved; Al’s success stems from understanding and adapting to how Steve plays. It’s a testament to the power of strategy, observation, and adaptation in achieving success.

This anecdote resonates far beyond the realm of poker. It underscores the importance of recognizing patterns, learning from experiences, and being open to change. Steve’s realization that to overcome Al’s advantage, he needed to alter his approach serves as a reminder of the necessity of adaptability and flexibility in facing challenges and pursuing goals.

In life, as in poker, we encounter situations where our usual strategies may not yield the desired outcomes. It’s during these moments that the ability to step back, reassess, and adjust becomes invaluable. Whether it’s in personal relationships, career endeavors, or everyday decisions, the willingness to learn, evolve, and try new approaches can make all the difference.

The poker parable teaches us that success is not merely about luck or innate talent; it’s about strategy, resilience, and the willingness to adapt. Just as Steve realized that to beat Al, he had to change his game, we too can navigate life’s challenges and opportunities by embracing a mindset of continuous learning, growth, and adaptation.

In essence, the poker table becomes a metaphor for life’s journey—a reminder that success often follows those who are not only skilled but also willing to evolve and adapt their strategies along the way.

So, this isn’t new, of course, we’ve all heard, that if life gives you lemons, you make lemonade. Which basically means, adapt. But, no one makes lemonade anymore, so I like mine better.

If you want to beat Al, you gotta change your game.

The Superhero Dilemma: Lessons from Little League Coaching to Software Engineering

Leave a reply

As a little league head coach, I recently encountered a situation that resonated deeply with my role as a manager of a software engineering team. One of the star players on my team of 7 and 8 year olds approached me after our championship victory, expressing disappointment about not receiving more recognition in the form of stars on his hat. This interactio led me to a realization about the dynamics of teamwork and individual contributions.

The young player, undoubtedly talented and a key asset to our team’s success, believed that he had carried a significant load throughout the season. In response, I gently reminded him of the essence of team sports. While his skills were commendable and his efforts invaluable, no player can single-handedly win games in a team sport like baseball. I pointed out that even the best player couldn’t field against an entire opposing team or hit, run the bases, and score alone. It takes a collective effort, with each player contributing their unique strengths, to achieve victory.

What’s more, I reminded him that he does have the most stars on his hat. He most certainly has gotten plenty of recognition for his contributions to the team, but that doesn’t mean we should only give him recogniton and not anyone else.

This scenario mirrors the challenges often faced in software engineering teams. Just as in sports, there are individuals with exceptional skills and capabilities—superheroes, if you will. These individuals may consistently deliver outstanding results and play a crucial role in the team’s success. However, it’s essential to recognize that no single person can carry the entire workload or solve all problems alone.

In the world of software development, projects are complex and multifaceted. They require collaboration, communication, and the combined expertise of a diverse team. Each team member, like a player on a sports team, brings their expertise, experience, and perspective to the table. Just as a baseball team needs pitchers, catchers, infielders, and outfielders working together, an engineering team thrives when everyone contributes their unique skills—whether it’s coding, testing, design, or product management.

The superhero analogy in engineering teams can be misleading if it leads to the misconception that one person can or should do it all. Instead, it’s about fostering a culture of collaboration, recognizing and appreciating each team member’s contributions, and leveraging collective strengths to tackle challenges and achieve success.

As a manager, I strive to cultivate an environment where every team member feels valued, supported, and empowered to excel in their roles. Just as in little league, where every player receives stars on their hat not just for individual achievements but for their contributions to the team’s victories, in software engineering, recognition and appreciation should be inclusive and reflective of collective efforts.

The journey from the baseball field to the software development arena unveils timeless lessons about teamwork, collaboration, and the power of collective contributions. Whether coaching young players or leading seasoned engineers, the essence remains the same: success is a team effort, and every player—every team member—plays a vital part in achieving it.

Practical Agile Guide Be Damned

Leave a reply

Quick Note

So, I’m not writing as often as I want to here. I guess it’s because I painted myself into a corner early on last year about wanting to give some specific advice that is practical and useful, but honestly, that’s just not as fun as some of the other stuff I want to write about. So, today I’m gonna write what will be my last blog in this series. I guess I’m saying that I’m not gonna finish the series I meant to finish in the way I imagined I’d finish it.

This article today will be a brief way of closing out what I started, in the best way I think I can.

Retro-duction

Let’s take a moment to recap the key themes from my previous posts on agile development. We’ve discussed:

The beauty and simplicity of the Agile Manifesto
How agility derives from values that emphasize individuals, collaboration, and adaptability
And why we should focus on the manifesto rather than prescriptive methodologies like Scrum or SAFe.

Then, we categorized the principles into

communication
delivery speed and iteration
people
quality
and workflow agility

We did that to provide a framework for analysis and action. We began outlining a practical guide, featuring the recognition of issues and matching them with agile practices, which led us to understand the critical building blocks for agile solutions.

Now, it’s time to briefly build on these insights and then to quickly conclude them. I’m going to be hoping that if you can’t put what I’m saying here into practice, because well, I didn’t do what I said I was going to do by being really practical about how to do that, that you’ll except what i’m saying at face value given my experience.

Lets Wrap This Up In A Tiny Little Bow

As we dig deeper into the world of agile software development, it’s essential to remember that the final destination is not to blindly follow a set of rules but to create a culture where continuous improvement is the norm, collaboration is key, and delivery of value is rapid and consistent.

Embrace the Manifesto as Your Compass: Whether you’re managing a team, coding, or strategizing as a product owner, the Agile Manifesto is more than a document it’s your North Star. Keep its values close to your heart, and its principles at the forefront of every decision.

Lean into Kanban: I’m not saying Kanban is the only thing you can use to be agile, but it’s by far the closest any documented or regimented process is to the principles in the manifesto. I’m gonna throw this out there; stop sprinting. If you remember what we’ve gone over in previous articles, see principle number 8 of the manifesto, and someone please tell me how you can be consistent and sustainable if you’re sprinting. You can’t sprint forever. Lean into Kanban for an easy interface towards true agility.

Visualize Your Work and Workflow: This one is actually much harder than it seems. Guess what, people are resistant to others knowing the state of their work. Also, I’ve found that most teams really hate the idea of having 15 columns in JIRA or whatever tool you use. But I can’t stress this enough. Until you consistently know the state of of your teams work items, you won’t get your stuff together as a team. You need to visualize the entire workflow from when a change request comes from a customer request, all the way to when that change is put into production. Same with bugs. You can make distinct worktypes if you have the team and manpower for it, but just know that you need to visualize the work. The good news is that I promise after you’ve broken down the work into steps represented by dozens of columns if needed, over time it will change and you will eliminate many if not all the extra ones.

Champion DevOps Culture: The DevOps “movement” or whatever you want to call it is a direct result of following the agile principles. Continuous Integration and Delivery are not mere buzzwords for trendy engineers, they’re actually incredible tools for delivering software fast, getting feedback and iterating. I can’t spend too much time on this one, but read Continuous Delivery by Dave Farley or Continuous Delivery Pipelines also by Dave Farley, or watch his YouTube channel (Continuous Delivery), to get a real sense for what Continuous Delivery and Continuous Integration really are. I find that most teams think they’re doing CI or CD because they have a CI/CD tool like Jenkins or Github actions in place helping them deploy. That doesn’t make a CI / CD process. Find out if you really are or are not, because true CI will change your team’s ability to deliver fast with quality.

Quality Comes With Quantity: Writing software is a scientific pursuit that thrives on experimentation. Invest in tools that allow your team to quickly analyze the changes being made and determining if they work. I know I’ve moved on from talking about CI / CD since I mentioned it already but I can’t stress enough how important a pipeline that has tests is to the quality of your application. And, the more your team delivers, the faster the tests will get, and the better the quality of results will be. There’s a lot as to why this is the case, but suffice it to say, that the old addage of quality or speed, isn’t true anymore, or at least it doesn’t have to be.

Communication Reigns Supreme: In Agile, clear communication is key. Shatter the silos, dispense with needless documentation, and channel the power of face-to-face meetings and calls. I’ve seen tickets written by some of the best ticket writers I’ve ever met, and man how I’ve wished they would have spent even just 90% of the time they wasted writing their super amazing gherkin for the acceptance criteria on just pairing with the developer doing the code. There has never been a ticket with enough acceptance criteria to ever save more time than had the product owner, business analyst, or whoever, just prioritized the work being coded, at that time, and sat with the dev to answer all their questions in the moment. This applies for developers on a team as well. Stop commenting on tickets or pull requests just to wait 2 or more hours for another developer to respond. You have a problem with a PR? Call your teammate and tell them, and fix it with them IN THE MOMENT.

Metrics That Matter: Stop using velocity and story points, start using DevOps Research and Assessment (DORA) metrics to tell the tale of true progress. Measure deployment frequency, lead time for changes, change failure rate, and time to restore; let data that data tell you what you need to work on as a team. Use additional metrics such as cycle time or PR wait times, etc. only if and when the DORA metrics are telling you there’s something wrong.

Trust Your Team: If you have the great fortune of working with a team that isn’t contracted or outsourced, take full advantage of this. Now I’m not saying that you can’t be agile in the way I’m describing it with a contracted team, but I will say there is a different dynamic there. In so far as you can, you should try and include a contract team in the same way you would a team of non contractors. With that out of the way, trust your team. By and large, if you have a team of smart people on a team, they’ll get the job done if you give them the tools and support they need. And, by team, I mean you too. Managers, or coaches, or leads, or whatever you want to call youself, you’re a part of the team, just the same. That means that stuff that they might thing isn’t important, like building a workflow, understanding cycle times, etc. all that is actually pretty important to making a team efficient and effective. I’ll add one thing here as well; don’t worry about the size of your team, it’s only too small or too big if you see that there are problems. Don’t get hung up on cool catch phrases like “two pizza teams” or whatever the “Scrum Guide” says. If you’re team is able to deliver, who cares.

Retrospectives: Conduct these often but keep them light, make them a conversation, not a soul-crushing reiteration of a performance appraisal. And yes, these can be hard to do, as different team members engage in different ways. But it’s important that you hear everyone’s perspective. Don’t let retro’s become fluff fests where no one actually says what’s bothering them, what’s hurting the team’s performance, and then discussing how they can try fixing it. Do be careful however, as you don’t want retro’s to become open areas for picking on or attacking individuals, you’re facilitation of these in a fair and just way is important. You should know before going into a retro, what’s likely to come up in it. If anything gets too intense, just pull it out of the meeting when it’s happening. By and large though, most engineers are pretty down to earth and can manage their emotions and social interactions well. But make sure you are doing these frequently. Every other week, or maybe even at the end of any big feature completion.

Conclusion

And there it is, I’m done. While it didn’t turn out exactly how I’d imagined it at the beginning of last year, and it’s taken way longer than I had as well, I’m happy about how I’m concluding it.

In the future, I’m going to be posting agile related blog posts, about my experiences as a software engineering leader. I hope you enjoy these. See you soon!

Practical Agile Guide Part Two: Building Blocks of Agile Solutions

Leave a reply

Introduction

In our first installment, we acknowledged the elephant in the room: recognizing that your team’s current processes might be hindering rather than helping. We opened up lines of communication and began a journey towards true agility by facing these issues head-on. Now, it’s time to start laying down the practical steps towards improvement, setting the stage for specific strategies in later discussions.

I won’t lie, there’s gonna be a lot in this one. I want to cover for you in one article as best I can, a myriad of problems I expect your team communicated to you or you identified, and then I want to give you some practical advice / tools on how to resolve them.

Agile in Action: Applying Theory to Practice

Step 1: Prioritizing the Problem List

Before diving into solutions, let’s categorize the concerns your team voiced. This will help us tackle the most impactful issues first.

Categories of Concerns:

Process Bottlenecks
Team Dynamics
Quality Assurance
Delivery Pace

Process Bottlenecks:

Lengthy PR reviews, unclear workflow visibility, too many sign offs. How does this probably look, or how can you identify these from the myriad of complaints you’ve received or the problems you yourself have noticed and documented.

Let’s start with lengthy PR reviews… if you have a PR that’s been in review for more than a day, that’s too long, period. So, start there, now, if you’re team is complaining that people on the team aren’t reviewing PR’s regularly enough, that’s a sign.

Unclear workflow visibility is pretty common. So how do you know if it’s an issue people are complaing about? Let’s start with this first, your team won’t tell you this. There’s something important to know about engineering teams and people in general (in my experience), the less clear a workflow is, the more work or moreover no work can be hidden. So what do complaints here look like? Usually it’s management or product team people complaining about not knowing when something was completed, or how much longer something might take. It’s an even worse problem when the engineers (devops, developers, testers) are complaining of not knowing when to start their work or their piece of a work item.

If you have more than 1 sign off, in the form of a PR you have too many. So that’s an easy one to identify. Sure, there may be some super high security reason in some places to have more than one, but there are some great techniques even in those cases to mitigate slow downs based on those sign offs.

Team Dynamics:

Interpersonal issues, trust deficits, lack of collaboration, overly nitpicky comments on Pull Requests. These are the worst kinds of problems, and they manifest in so many different ways.

Trust deficits are team killers and truthfully can manifest in ways that look like complaints in other areas. For example, lengthy PR reviews are usually caused by trust deficits amongst the team. So, if you’re having PR reviews that are too lengthy, like mentioned above, it’s also probably a team dynamics issue. Another trust issue is when you have one or two engineers on a team always looking at other peoples code, before, during or after they’re pushing up their changes. Cross specialization trust issues are pretty easy to identify, for example the engineering team complaining that product isn’t writing enough details into the tickets, or the product team complaining that the engineering team isn’t doing what they’re asking.

Lack of collaboration is really hard to determine, but know this. If your team isn’t regularly meeting to discuss their work, they’re lacking collaboration. A good sign is that team members spend a lot of time breaking work items down into very specific and tiny tasks up front. Yeah that’s right, this is not a good sign. Sure it might make estimating seem like it’s easier or more effective, but really what’s happening is your team wants to just have their tasks and not be bothered till their done with it. Moreoever, down below, I’m gonna tell you something about estimating and how to do it better (hint: don’t do it).

Quality Assurance:

Flaws in the product, unsatisfied users, lengthy test cycles, finding unimportant bugs and holding up releases. All these are problems in quality that are pretty easy to identify. But what’s more likley the case, especially early on in your agile team building process is that these are side effects of poor collaboration and poor trust. After you’ve got a team that is doing those things better, you’ll have less quality issues and then the ones you do have will be about something in your workflow or possibly some legitimate non team specific thing related to your code or infrastructure.

Delivery Pace:

Inconsistent speed, missed deadlines, overcommitment, missing sprint goals. As a category of problems this one is easy to identify, or at least it’ll seem easy. Why do I say that, well because let’s get real, who’s to say what’s slow or fast. There’s a good chance that your team is building something that either hasn’t been built before, or if it has, only a few people on the team have built it before or something like it, and then what bar do you have to measure speed against.

But that aside, as a team, if you’re missing deadlines or the team is overcommitting it’s easy to see this becasue well you missed deadlines or probably didn’t deliver all the tickets within a sprint.

Step 2: The Agile Toolbox

Agile isn’t about blindly applying practices; it’s about understanding the why behind each action. We’ll introduce some universal agile tools that can address a wide array of problems.

Before hopping in, I’m gonna tell you something and you may not want to hear it. More over it’s gonna freak you out some too. The tools and techniques I’m going to suggest below are likely going to be wholesale changes in the way you work. The reason is simple, it’s what I know, first, and second, it’s not a boxed off the shelf solution like SCRUM or SAFE, or anything. Lastly, as a so called Certified Scrum Master I’ve seen Scrum fail miserably to meet the needs of a great development team and workflow. My approaches, techniques and tools are much more agile manifesto principles based now and they’ve worked wonders.

Let me give you some info to help you understand where I’m coming from. I’m an evangelist for the manifesto because I’ve seen it in it’s purest form work. What’s more is that I’ve seen the offshoots of the manifesto really work well. For example, DevOps, Continuous Delivery, Value Stream Management, etc. these are all methodologies, concepts, practices that have their foundations in the agile manifesto.

If you want to understand these concepts better check out my Resources page on the best books, podcasts, videos and creators to follow on these topics. With that information, here goes nothing:

Stop sprinting, it’s not sustainable
Stop giving work to frontend people and backend people and devops people and QA people separately, instead work as a team on one or two items
Start a continuous delivery workflow immediately
Stop measuring velocity and more importantly
Stop estimating
Delivery smaller chunks of work that have value
Lastly, break up your workflows visibly so that you and the entire team can see all the true steps and details that are happening.

Now that you have a base, let’s get into the tools and techniques a bit more that can help you do what I just described.

Agile Tools and Techniques:

Here’s the tools we’ll be discussing

Make Work Visible: Understanding and laying out the real state of a change and it’s flow through your team on its way to production is important.
Kanban Boards: Visualizing work in progress to increase transparency and identify process inefficiencies.
WIP Limits: Limits on the amount of work in progress help teams stay focused.
Metrics are important but some are proven to be much more effective and useful than others. DORA metrics are way you should start.
Stand-ups: Daily check-ins to synchronize team efforts and identify roadblocks early.
Pair Programming and Team swarming: Enhancing collaboration and code quality while reducing knowledge silos.
Less Documentation More Communication: Documentation is great for a lot of things, but not communication of needs and details.
Continuous Integration/Continuous Deployment (CI/CD): This buzzword isn’t just that, it’s actually an integral part of delivering high quality software.
Retrospectives: Regular reflection and adaptation sessions to incrementally improve team practices.
Iterative Development: Don’t eat the pig, eat the frog. Disgusting I know, but understand that delivering small valuable chunks is way more effective.
Teams Solve Probelms They Don’t Implement Features: Don’t build features, solve problems that features fix, and do it AS A TEAM.

Step 3: Implementing Agile Tools

Now, let’s explore how these tools can specifically address the concerns you’ve identified.

For Process Bottlenecks:

Make Work Visible: That’s right, taking your boards from “To Do”, “Doing”, and “Done” to “To Do”, “Doing”, “PR Rejected”, “Pending QA”, “In QA”, “In PR”, “Release Ready” and “Done” will change your life and understanding of your workflow (btw these were some generic states of code I put together, you’ll need to determine what states matter to you and your team). What’s important is that you and the entire team has a clear understanding of the state of a requested change, from when it’s requested to when it’s in production.
Kanban Boards: Adopting a Kanban approach could illuminate the current state of work, showing where tasks get stuck and why Susan’s tickets take so long. So if you add states to your workflow, the Kanban Board is the best method to see them. This is much bigger a thing than I’m doing it justice in this section. Kanban is fantastic because it seems to me the most natural exentions of the agile manifesto, in terms of a methodology. This one’s gonna take a bit of research to understand more about pulling not pushing work, and how that works and why. Do the research… this will pay itself off in spades.
WIP Limits: Implementing work-in-progress limits can prevent overcommitment and ensure focus on task completion. Also, WIP limits help with understanding how a Kanban workflow operates. So, what does this look like in practice? It’s simple, decide as a team on the number of items the whole team can have in the in progress states of a feature (so that might be a group of states such as in progress, QA, release ready), and then say when that number is met, no new work can be started. Ok, but Andre, then what does frontend do when there are no in progress tickets for the front end. Well, front end in that case, does everything in their power to help out whatever is in progress, maybe it’s reviewing tickets in PR, or doing some QA work, or maybe it’s simply sitting in and learning and getting more application domain knowledge from the backend folks until there’s space for more work. And this applies to everyone on the team. I told you, this is a big topic, maybe I’ll cover it in more detail at some point down the line.

For Team Dynamics:

Stand-ups: These can foster better understanding and collaboration within the team, as well as early detection of interpersonal issues, but drop the… “what did you do yesterday, what are you gonna do today part”, who cares. Just ask and determine what’s blocking them from moving their work, today. If you’re implementing Kanban, you’ll learn that the most important thing isn’t what’s been done, it’s how to get a work item from where it is now to where it should be as fast and effectively as possible. One more quick thing, because we’ll touch on it a little more down below, but stand-ups are not a replacement for team meetings and collaboration.
Retrospectives: Offer a safe space for discussing non-technical issues that affect team morale and collaboration. My favorte approach to a retro is to use the lean coffee style. Look it up, it works a treat. Something to note is that you should do these every other week or so, and probably once after every major feature / function / project release.

For Quality Assurance:

Pair Programming and Swarming: This practice can help improve the quality of the codebase and share ownership of the product’s quality. You don’t have to do this in that very specific pair programming way. A great technique I’ve found here is to have a few hours or sessions a day where the team just works together on their own thing. So, maybe pop open a zoom or huddle or whatever and everyone does their own thing. After some time, this magical shift in how they work and what they’re working on happens. Soon you’ll see they are all working on the same item and completing it faster and with more quality.
Less Documentation More Communication: If youre product and development team members are at odds over the details of a ticket, then stop making detailed tickets, and instead communicate more about a ticket while a developer is actually working on it. Let’s get this out of the way right now… there is NO AMOUNT of documentation that can ever convery what you need something to do, in enough detail that there won’t be misunderstandings, period. So why do we pretend that there is. Why do we constantly go back and forth on the details of a ticket and fight over whether or not the intent of a delivered feature was met or not. Instead of writing down every last detail, make the product team work on the same tickets that the engineers are on. They should be in those team discussions while engineers are working on a ticket so they can answer any of the hundreds of questions that arise during the development of a functionality.
Continuous Integration/Continuous Deployment (CI/CD): Introduce automated testing and deployment to receive faster feedback and ensure a quality product. If you did nothing else, you had better get on this train and fast. The entire industry is moving or has moved to this and if you don’t your company will be left behind. And let me state that I don’t make fake CI / CD. I mean real CI / CD. See my blog on books and videos for some more insight on this, it’s big topic. But suffice it to say, you need more tests than you think you do, and you need less sign offs.

For Delivery Pace:

Iterative Development: By working in smaller increments, the team can adjust more quickly to changes and deliver value more consistently. This one is a hard practice to really solve. The practice of doing smaller increments requires your WHOLE TEAM, including product people and even mangement / leadershipt to think differently. You should be in the habit of making small valuable improvements and collecting feedback from your users, regularly, and quickly with every, very reqular, release you do. Feedback can be in the form of pure data, and in other instances it can be in the form of just asking them. So, if you are looking down the barrel of a huge problem, work as a team to break it up into smaller deliverable chunks of value that your team can deliver. There’s techniques to help with this as well, such as feature flagging or canary releases, etc. Just strive as a team deliver less more often and this will come together.
Teams Solve Probelms They Don’t Implement Features: Yup, you heard that right. If you want faster delivery of quality software, then don’t think about your team as contractors, your team is there to solve engineering problems. Your team is probably made up of a product person or two, a designer, a frontend person or more, some backend folks a devops skilled person and maybe some QA and a manager of some kind. Everyone I just mentioned is a part of the team. They all have different specializations but they should all be involved in understanding the problem and helping solve it. Product collects feedback from user and outlines the problem, they involve the team to find a solution, together that meets the business and user needs, designers create some nice visuals that meet the needs of the solution, QA helps devise early tests to implement throughout the dev cycle, the engineers do the implementation a manager helps ensure a collaborative and functioning workflow, and devops creates or adapts infrastructure to deploy the changes into. Then the cycle starts again with product understanding how the change impacted users, and then identifying new problems to solve.

Step 4: Measuring Success

As you start implementing these practices, establish clear metrics to measure their impact.

Potential Metrics:

DORA Metrics: If you do nothing else, implement these. Again see my post on the different books, videos, etc that I love, in order for you to understand more aout the why. But suffice it to say, that these metrics are proven to be the most important ones in the industry, and here they are:
- Lead Time for Change
  - Depending on the maturity of your continuous delivery workflow this can be a measure of how long it takes from when a PR us approved to when it’s in production OR if you have a really mature CI workflow, I’ve found it helpfule to expand the scope of this metric to include the entire process from feature or change inception to productition deployemtn.
- Mean Time to Restore
  - How long does it take from when you identify a production bug or issue to when you’ve deployed that fix into production.
- Change Failure Rate
  - How many changes result in a failure over the number of deployments your team has delivered in a given time span. Some might use generally any bug that is in production, but this will depend on your team’s maturity and your app’s maturity level.
- Deployments / Releases
  - This is an important one. Keep a count of the number releases / deployments your team is making in a time period. The more you make, the better your team will be and the more quality your app will have. Now, I know you’re like, WHAT? But yes, the data is clear on this, if you make this metric important within your team, the team and more likely the organization will reorient itself around it, and the results of that lead to more quality (because you aren’t releasing changes without issues if they have bugs), faster feedback loops (because your team is gathering information after every change), and doing less useless work (because your focused on just those important piece of feedback and making small changes rather than frivolous changes).
Cycle Time: This is an important metric but you have to determine what cycle to measure. Focus on lowring the cycle time between steps in the workflow that smell like they are taking long. And since you’ve implemented a very visible workflow this shouldn’t be too hard.
Work Items Completed: So, if you followed my advice above, you aren’t sprinting and you don’t have any velocity. There’s a great way to still have a good sense for how the teams doing and that’s just simply counting the number of work items completed in a given time period and then tracking that. This number will fluctuate and change overtime, but it should remain within some standard deviation. Why? Well becasue the more a team works together, the more it sizes solutions similarly to other items, and the more they solve them in similar ways. Teams will find a natural equilibrium. But what is still true is that different problems will always have different solutions so don’t use this as a bar, just follow the trend and if it is trending downward, use it as a red flag to determine what could be, if any, the issue.

Conclusion

In this chapter, we’ve set the foundation for applying agile principles to our recognized problems. These building blocks are designed to be versatile, forming the basis for the customized solutions we’ll develop in subsequent parts of this guide.

As we look forward to the next installment, remember that agility is as much about mindset as it is about methodology. Embracing change, seeking continuous improvement, and fostering a collaborative environment are the true markers of an Agile team.

Stay tuned for part three, where we’ll take a deeper dive into tailoring these agile practices to our unique challenges, ensuring each solution is not just a band-aid, but a step towards sustainable agility.

Thank you for following along, and remember, the journey to agility is ongoing, but every step counts.

Practical Agile Guide Part One: Recognition

Leave a reply

Introduction

If you’ve bothered to read my other articles, you must be thinking what I always think when I read stuff about Agile on the internet, and that is… “so how do I do it?” No one ever gives a real practical agile guide. And it’s true that reading about Agile doesn’t normally help you understand how to practically implement Agile. And while I don’t think there is any such thing as “implementing agile”, there are certainly practices and patterns of working that are more agile than others. And, in my view at least, if you’re practicing those principles and following those patterns, and most importantly having success in your projects, then well… you’re Agile.

What I intend to do now that the high level stuff is out of the way, in previous posts, is to create a practical guide over the next 5 to 10 blog posts on some common practices and patterns that can help you and your team find success through adherence to the agile manifesto. I don’t plan on beating you down with principles one by one, instead I’m going to piggy back off the earlier posts I made about the categories I’ve personally broken the manifesto down into:

Communication
Delivery Speed and Iteration
People
Quality
Workflow Agility

Before jumping in, I want to say the following; the practical examples I’ll be using are examples of work I’ve done myself. They’ll be examples of interactions, or situations I’ve been in. In almost all these circumstances they’ve been with between one to 5 agile teams. That is, I’ve almost exclusively done my work in the startup world. While I am fairly confident that these practical implementation examples and advice would apply in larger team settings, I can’t guarantee anything. In fact, I can’t and don’t guarantee anything no matter your team size, these are my experiences and I’m sharing them to help you understand how being agile helped me and my teams.

Also, it’s important for me to say that this “Guide”, while it has an order, it isn’t something that you should expect to follow and be done with. As you look at the categories above, they are descriptions or parts of everyday work. That is, you can’t just jump in and start working strictly on the “Communication” problems the team is or isn’t having and then when you’ve got that all figured out and working you then move on to the “People” category and then figure that all out. I mean, maybe you could do that, but for me each of these categories is part of a delicate balance. One day you realize that communication isn’t effective, but it had been more effective a few weeks ago, so you need to work on it again, but what changed? Maybe people were added to the team, maybe a change in the workflow had an effect, maybe the quality of the product is making people upset or lazy. Any number of factors can be at play, and so, each of these categories are part of an ongoing process of improvement. You’ll never have them all perfect, and you’ll never be done trying to make them perfect.

This guide will use some or all of the categories above in each part. I’ll be sure to call out what is what and when, as well as maybe what principles we’re looking to for guidance. And without further ado…

Day One – Something Smells Wrong Here

Let’s set the premise for our upcoming adventure. You’re a:

engineering manager
agile coach
team lead
developer / engineer / programmer
product owner / manager

The list can go on and on, but the point is you’re on a team and things aren’t going so well. Your team is delivering software but any number of things don’t feel right. Maybe it’s taking much longer to get changes into the hands of your users than you think it should be taking. Or, maybe your moving fast, but the users are really not liking anything that your team is giving them. Maybe there’s a lot of turmoil on the team and every team meeting is full of stress, resentment, and palpable dislike or distrust between the team’s members. Maybe the team is burnt out, unhappy, and you know that certain members are looking elsewhere for a new job.

I want to point out that anyone on a team can recognize a problem, and anyone on a team can start the process of becoming purely agile. It just takes one person on the team to understand that there’s a serious problem and it’s affecting the output of the team negatively.

Another very important thing to point out is that there’s no reason to become agile if you aren’t having any problems. I mean that. If you’re on a team that practices old school waterfall, or even scrum and your users are happy, the team is happy, and the company is making money… then don’t change anything. I mean, you should always be looking to learn and improve, but there’s no reason to undergo a long process of becoming purely agile if some process is already working.

Does Anyone Else Smell that

You’ve identified a problem, but are you the only one whose noticed? Step one is going to be for you to validate your concern with the rest of the team. And, in truth, this first step is actually a part of the process. Being open and honest with your team, and having them be open and honest back is an important part of, you guessed it… Communication.

In your next team meeting, take a risk and present your concerns to your team. See what they have to say. Maybe your thoughts aren’t heard because there’s antagonism on the team from other members. In that case, ask your team lead, or manager, or agile coach or a product manager or anyone that isn’t antagonistic, if they smell the same thing you do. But it’s going to be important to have some level of recognition from the team that there is an issue and you think the team could be doing better. Again, maybe better means, happier work life balance, or happier users, better quality delivery, faster deliveries, less stress in meetings, less fighting, etc.

Let’s move forward under the assumption that you’ve taken the risk, and the team has validated your concerns. What’s more, each of them also has concerns, or more likely, specific complaints. The process is to strict, or Jack doesn’t review any PR’s ever, he leaves them to everyone else, or Susan always picks up the bulky tickets and then takes weeks to deliver them, or we never deliver all the tickets we committed to in the sprint, and then we always have more in the next one… the list of complaints or concerns can go on and on.

CONGRATULATIONS! You’re agile… OK, not really yet, but damned if I’m not proud of you. You’ve just done something very hard. You’ve communicated in a way that not a lot of teams do. Very few teams are actually open and honest, and you’ve managed to make that happen. Heck, we could even say you’ve had your first real retrospective.

Whoever Smelt It… Now Has to Check Everyone’s Pants

What a great heading, am I right? But seriously, it’s not enough to just smell a problem and then think you can fix it. Nope, you have to identify the problem as best you can and even write it down so that you can look back and gauge the change over time. So, listening to your team, write down all their concerns, and be sure of course to document yours. You can’t say you’ve done good change without knowing what you’ve fixed.

These can be abstract ideas, that is, sometimes it’s hard to pinpoint a problem and be specific about it, in that case just write down what it feels like as best you can. For example, an easy problem to write down is that Jack thinks that Susan’s tickets are taking too long to deliver. It’s a harder to be specific about people issues like the feelign that ego amongst team members is getting in the way of progress. Sure you may have examples of when it has done so, but its not likely everyone on the team will agree, so it’s a subjective issue. But write it down anyways. Or, how about the idea that you think the work is taking so long because there isn’t any clear visibility into work in process. I mean you agree with Jack about Susan but have no way of proving it because there’s only a To Do, Doing and Done state for the work. Just write it all down.

Anyway, You’ve talked to your team and they agree there are problems and that things could be better. You’ve now documented all the things you think are the problem, and you’ve asked your team to do the same. It’s time to get together with the team again. It might be a week later, or two weeks later, but don’t let too much time pass since you had that first meeting confirming there were certainly problems. This time, have your list of concerns and issues that you and the team communicated, and then one by one in a meeting share them, and ask the team for ways they think can fix the different issues.

This is going to be chaotic. Depending on the level of trust that exists on the team this could feel very useless or it could be very scary. What will be important as a facilitator is to share with the team the following. Your going to time box discussions on each concern, and if you don’t have a documented next step on it, that’s OK you’ll move on, and discuss it again in a future “retrospective”.

That’s right, you’re having a retrospective. In more agile manifesto terms, you’re team is “reflecting on how to become more effective, then tuning and adjusting it’s behavior accordingly”. This action encompasses Communication and People from my big five categories. There are a lot of guides on how to conduct a good retrospective, I may write my own someday, but for now, it really is OK to just use a spreadsheet, and a timer to accomplish the goal of trying to get ideas for how to solve each of the concerns / complaints of the team from the team.

I realize I’m not being very specific or practical here, so let’s get simple here. You talked with your team at some point and realized that you weren’t the only one that felt there were problems. So, schedule a meeting. In this first meeting write down your concerns, and any that your team has as well. Don’t worry about trying to solve them yet, given this is maybe your first time talking about these problems with the team, it can take a while. So let them know there will be a second meeting in a week or two. Schedule the second meeting. When the day comes, in the meeting tell the team that you’re going to time discussion about solutions for each problem. If at the end of the timer no solution has been given, move on to the next problem. Let them know you’ll come back to those other ones another day, say in two weeks (same day / time). The point is to make progress where you can, and if discussion on one problem is too long, it likely needs a lot more attention, and it will keep coming up anyway.

The first thing you should do after the meeting is share the notes you have so far with the team. Then, make tasks to implement any of the easy solutions the team was able to agree on. Then, schedule the next meeting (retrospective), to continue discussion on the other points. Lastly, ask them to share anything else between now and the next meeting that they may have thought of.

So, there… put that into practice.

Conclusion

You’ve done a lot so far, and I’ve written more than I planned to for part one. Let’s agree to stop here(ish). You’ve recognized a problem. You’ve shared it with your team and they’ve shared their issues back. Again, big accomplishment. Then you held a retrospective to start getting feedback from the team and understand ways you and they think can solve the problems.

You and the team are being agile in that respect. It’s not however easy to say that just because you used agility to understand, document and propose solutions to several problems that those solutions are agile. In fact, it’s quite likely that many of the solutions proposed by your team are not at all agile. So, that’s what we’ll start exploring in coming additions to this series.

In part two, we’ll discuss what that list of problems your team made likely includes. But we won’t go into specifics on any one of them, for now, because in even more future articles we’re going to dive into each of the issues (at a categorical level) and solutions or practices to help mitigate / rectify them.

What we will however do in the next article is discuss some generic agile practices that can help with many of the issues you and your team probably wrote down. These will be practices that you can start right away, and you can easily gauge their success or failure. It’s likely that many of these practices will be reused / discussed when we dive into specific issues in future articles, so this will help setup a good premise for you to understand how they can help now and with specific issues.

Thanks for sticking around, see you soon.

Simplifying the Agile Manifesto: Breaking it Down Into Categories

Leave a reply

Introduction

In this blog post, we’ll explore Simplifying the Agile Manifesto by breaking it down into high-level categories. These categories will help us better understand the key concepts and principles of agile methodologies, enabling us to apply them more effectively in our daily work. I’ll say the following more then once in this post; these are my categories, I made them to help me. I caution you that you may feel differently, and I don’t want you to get the idea that the Manifesto itself is represented or supposed to be breakdown by categories, it isn’t. I just did this for me, and I’m going to share this with you.

The Agile Manifesto is great. Ok, obviously that’s something I’d say considering I’m writing about it. But, I can also say that it can be a bit long. Or at least, if you wanted to start practicing and adopting it’s ideas practically the fact that there are 16 lines of individual thoughts or concepts makes it a bit daunting. It’s certainly not as daunting as having to memorize how to run a scrum team, or knowing how to implement the SAFE methodology, but even I won’t pretend that by just reading it you’ll know what to do next on your team.

What is true though is that you should do your best to memorize the manifesto. And I’ve always found things easier to remember if I can break them down into categories. So when I started my agile journey, that’s what I did. I broke the manifesto down into 5 high level categories, and placed the principles into them based on the content of the principle. This post will be about those categories, and it’ll help serve as a way for future blogs to cover the specific categories in more detail.

Manifesto Categories

If you take each of the principles on their own, each has a lot to say. In future blog posts I intend on diving deep into each principle, but for now, I have 5 categories that I believe we can divide the principles in to. And that each category on it’s own has a lot to say without having to know or remember anything about the manifesto’s individual principles themselves. That is, the categories themselves can enable us to apply the principles more effectively, even if we don’t know or remember the principles. They like the principles, principles.

Communication

The Agile Manifesto places a strong emphasis on communication, recognizing the importance of individuals and interactions over processes and tools (which itself is one of the principles). This category encompasses principles such as:

Customer collaboration over contract negotiation
Business people and developers working together daily throughout the project
Face-to-face conversation as the most efficient and effective method of conveying information within a development team

While other principles could also fit in here, they fit better in other categories, but what is important to take away from this category is that talking to someone, being available to communicate your team, and not expecting that some document or ticket is ever going to be enough. That is, don’t think that just because you wrote something down, that that will be as effective a communication tool as actually telling someone something.

Delivery Speed and Iteration

Agile methodologies prioritize delivering working software quickly to satisfy customers and provide value. The principles in this category include:

Working software over comprehensive documentation
Satisfying customers through early and continuous delivery of valuable software
Delivering working software frequently, with a preference for shorter timescales

By focusing on rapid delivery, agile teams can better respond to changing customer needs and market conditions, ensuring their products remain relevant and competitive. To achieve this, you need category number one, communication. If you don’t communicate you end up having to document, and documentation is slow. You want to be able to make small changes that you can put in front of someone so they can tell you if it works or not.

People

The Agile Manifesto acknowledges the importance of people in software development, emphasizing the need to create an environment where motivated individuals can thrive. The principles in this category are:

Building projects around motivated individuals and providing the necessary support and trust
Promoting sustainable development for sponsors, developers, and users
Encouraging self-organizing teams to produce the best architectures, requirements, and designs
Regularly reflecting on team effectiveness and adjusting behaviors accordingly

By empowering people and fostering a culture of trust, agile teams can improve productivity, job satisfaction, and overall project success. This category to me is one of the ones I think isn’t considered as a category in and of itself by most other breakdowns of the manifesto. But to me its very important. People make software, and people are important. As a specialist in startups where it’s considered normal to sprint and burn out team members, I can tell you that losing team members to burn out is the worst loss in productivity possible. People matter.

Quality

Quality is an essential component of the Agile Manifesto, with principles that emphasize the importance of working software as the primary measure of progress and the need for continuous attention to technical excellence and good design. By focusing on quality, agile teams can ensure their products are reliable, efficient, and maintainable, ultimately delivering more value to their customers.

BUT… there’s a catch. Quality is very important, however, in my view, it’s less important if you’re a startup than it is if you’re a company or product that has found the elusive Product Market Fit. Now, that’s not to say that these principles aren’t as important if you’re in a startup, because they are. But I think their interpretation can be different for different products or stages of a product.

It’s sort of weird because quality is important for increasing the speed of delivery. Yes, that’s right, you can have fast and good, and in fact, for it to be good, it has to be fast… you’re gonna have to stay tuned to read me explain that. But suffice it to say, that quality is very important, but what kind of quality, that’s the question. Some teams think quality is a reference to how good their code is, or how well built the architecture is or how future proof and scalable it is. But that’s not what quality here means.

You want software that doesn’t break for the customer, and there are dozens of ways of making sure that your customer doesn’t get broken software, that don’t include creating 100% test coverage or making sure your architecture can scale for a future number of users you don’t have now. So, with all that said, remember that Quality is important, but what matters most is your customers experience… and they don’t experience the code.

Workflow Agility

The Agile Manifesto encourages teams to embrace change and adapt their workflows to accommodate new requirements, even late in development. The principles in this category include:

Responding to change over following a plan
Welcoming changing requirements for the customer’s competitive advantage
Pursuing simplicity by maximizing the amount of work not done

By fostering workflow agility, agile teams can quickly adapt to changing circumstances, reducing the risk of wasted effort and ensuring their products remain aligned with customer needs. And I know this is more easily said than done. People don’t like change, and managing change is hard. To put this into practice, you have to be able to create fast feedback loops so that you are prepared to show the team how changes are affecting your product.

Conclusion

Communication
Delivery Speed and Iteration
People
Quality
Workflow Agility

These are my categories, I’ve seen others and they may work just as well. I encourage you to create your own as well after you have a good understanding of the manifesto. Ultimately you’re the one who has to adopt, implement, and then adapt them to help your teams work better, so if you can break them down into meaningful categories that are like your own, principles principles, you’ll have an easier time of making them a part of your normal decision making process.

By examining the Agile Manifesto through the lens of these high-level categories, we gain a deeper understanding of the core principles that guide agile methodologies. By focusing on communication, delivery speed, people, quality, and workflow agility, we can better apply these principles in our own teams and projects, ultimately improving our ability to deliver value to our customers.

Being Agile Is Easy

Leave a reply

Introduction

The idea of changing from your current “agile” process might seem daunting at first, but adopting a pure, or what I call, true agile mindset doesn’t have to be complicated. Now, if what you’re currently doing is working fine for your and your team, DON’T CHANGE. I mean, you should reflect and update, but there’s no reason to change whole hog. However, I expect that if you’re here reading this right now, things probably aren’t going as well as you’d like. Don’t worry, being agile is easy.

You don’t need an advanced degree or years of experience to understand and practice the Agile Manifesto and its principles. In fact, the whole team, including software engineers, product owners, designers, QA members, DevOps professionals, and business stakeholders, can easily embrace these principles and enjoy the benefits of agile development. And yes, all those roles, are part of your team. An agile team isn’t just developers and a manager, the whole team is everyone involved in delivering value, and then learning from that delivery.

So, if you’re still reading, I’m gonna do my best to make a case for why you should drop your current methodology, especially if it’s some prescribed one like Scrum, or SAFE, and become an agile purist.

Simplicity at Its Core: The Agile Manifesto

The Agile Manifesto is built on four straightforward values that emphasize collaboration, adaptability, and customer-centricity:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

These values are easy to understand and can be quickly adopted by teams of any size or experience level.

Implementing Agile Principles: A Team Effort for Everyone

Agile development is a team effort that encourages open communication, trust, and shared responsibility among all members, including software engineers, product owners, designers, QA members, DevOps professionals, and business stakeholders. By working together, teams can easily put the Agile Manifesto’s principles into practice:

Remain adaptable and open to change based on customer feedback and evolving requirements, even late in development.
Emphasize face-to-face communication to build trust and foster collaboration across all roles.
Focus on delivering working software that provides value to customers.
Encourage continuous learning, improvement, and innovation.

By following these basic principles, teams can create an agile environment that promotes efficiency, creativity, and adaptability.

Being Agile Is Easy for Everyone

You don’t need to be an agile expert to put the Agile Manifesto and its principles into practice. By fostering a culture of collaboration, open communication, and adaptability among all team members, teams can easily embrace an agile mindset and enjoy the benefits of agile development.

To help your team become more agile, consider these simple steps:

Review the Agile Manifesto and its principles together as a team, involving all roles.
Identify areas where your team can improve communication, collaboration, and adaptability.
Implement small, incremental changes that align with the Agile Manifesto’s values and principles.
Regularly review progress and adjust your approach as needed.

Remember, being agile is about embracing simplicity, collaboration, and adaptability. By focusing on the Agile Manifesto’s core values and putting its principles into practice, your entire team can easily adopt an agile mindset and excel in delivering value to customers.

Over the coming weeks, I’m going to be posting more specifics on the topics above, like, what does it mean to be collaborative and adaptable, or how does a team move to small incremental delivery’s. So, hang in there, I’ve got a lot more to come.