My favorite part of being an agile coach is standing up a new team, whether it is a Scrum team, a Kanban team, or a Release Train team. It involves bringing together a group of individuals and getting them to operate as a single unit, towards a single purpose. And, it involves finding creative ways to bring people together.

The task of setting up a team varies based on the situation, the individuals, and the organization. But regardless, of the specific situation, I follow a 3 step process to standup a new team: make the group a team, make them an agile team, then make them a [insert framework here] team. My reasoning is quite simple: a Scrum team that is not also agile is missing the point of Scrum, and an agile team that does not operate as a team will struggle to function effectively.

In Part 1, we’ll discuss how to setup a team. In Part 2, we’ll cover how to make a team an agile team and how to make an agile team a Scrum Team, a Kanban Team, an XP Team, or even a Release Train Team.

Create a Team

When it comes time to kickoff a new team, I look to establishing the group’s identity, setup ground rules, define processes for collaborating, and for the team to learn about one another. It is this final piece - learning about one another, that becomes crucial to establishing a team. But all of these elements are necessary for setting up a team for success.

Group Identity

A group’s identity can be as simple as establishing a team name, or as complex as defining a mission statement, envisioning the end state, and establishing the team culture. I find that the team culture will evolve as the team grows - but a good name is a great place to start. It is the start of an identity, one that the team will build upon as they work together.

The first Scrum team that I coached picked the name “The Avengers”. From this, the team decided that each team member should pick a member of the Avengers to be their avatar. Anywhere in our development tools, it was easy to spot our team members, as we were the superhero team, working together towards a common goal. The morale of the story: find someway to incorporate the team name into the identity of the team.

Ground Rules

Any collection of people working together need to understand the boundaries of that group - the rules that define how interactions work. As human society developed and evolved, the rule of law helped govern people’s behavior and led to a well-ordered group. With a new team, we need to take time tto define how we will operate.

As we start up a new team, setting aside ground rules for how the group wants to operate jumpstarts the groups formation by codifying some of the expectations the group has on eachother. As the team starts working together, they may discover additional rules they would like to establish to frame how they work together. Feel free to add these to the list of ground rules, but be cautious about adding TOO many rules; you and the team will likely forget one or two and will decrease their value.

If your team is a multi-cultured team (meaning, not everyone hails from the same country, region, culture, etc.), you may need to discuss the different expectations of each person’s culture. For instance, some rules are so ingrained by an over-arching culture, that they are only noticible when you interact with other cultures. For example, Americans have a preference for a large amount of personal space, but going through our day-to-day lives, this isn’t noticeable until you encounter someone from a different culture that has a different view on personal space. Then, their closeness can be a bit unnerving to an American. These cultural differences will surface as the team begins to execute, but it may be worth while to discuss the groups cultural differences and decide how to resolve any challenges this presents.

Collaboration

As you move into how the team operates, you’ll begin to touch on the agile processes and practices that define the team. We’ll cover these more in part 2, but for now, let’s consider how does the team collaborate? In this part of the kickoff, I discuss:

• What are our core working hours?
• Do we want to establish some “focus time”, time where interruptions are highly discouraged?
• What tools will we use to collaborate?
• If using group chat tools, what rooms/channels do we want to establish? What will their usage look like?
• Do we have a preference for when we schedule meetings? Mornings, Afternoons, a particular day of the week?
• Do we need a team home page in our wiki/SharePoint/Blog or similar tool the organization uses?
• Do we need a email distribution list?
• How will we communicate with eachother primarily? Face-to-face, email, chat, phone, video conferencing? When are the appropriate times for each of these channels?

Based on your organization, your own experiences, or the experiences of the group, you may think of other items to consider here.

Team Member Identity

While this is the final portion in my list, I view it as the most important part. For teams to truly work well together, everyone must feel comfortable being themselves and bringing that person that person to work. Innovation requires lots of ideas to choose from. But in order to surface many different ideas, team members must feel safe in bringing them up. If a team member can be themselves, and free to pull from their personal experience, we can generate more and better ideas. But this goes for EVERYONE on the team, not just the most senior person on the team.

There are many ways for team members to share with the team who they are: you can ask questions, ask each person to talk about themselves, have team members interview eachother, or play a team-building game. Here, your imagination is your only limit to what you can do.

I have 2 go-to strategies for the teams I work with: a personality test and a team member cereal box. For the personality test, I ask team members to take the free 16 Personalities assessment and share with the team. As each team member shares, we make connections, discuss what seems most true about the assessment for us, and discuss how we relate to the other personalities. Depending on the familiarity of the group, I may ask them to send me the results and I’ll read them off to the group and ask them to guees. In this way, we surface how others currently see us.

The other exercise, adapted from Lyssa Adkins’ book Coaching Agile Teams, goes something like this: provide each team member with a blank cereal box, a piece of paper or a poster board as well as some art supplies (colored pencils, markers, pens, etc.) and ask them to enviosion themselves as a product. What do skills do they provide? What is the experiences they bring? What is this person’s brand? But also ask them to focus on what they want to become. Do they wish they knew more about testing? Front-end development? Database design?

Once everyone has designed a cereal box or poster, ask them to share with the team. As people go around the room, ask the team to ask questions and to chime in where they can help the team member gain some of the skills they want to grow. Not only will team members walk away with a better understanding of each other, but they will have some ways to build upon the team bond as the team works together and helps each other.

Conclusion

Teams are amazing groups of people, but they don’t form overnight. Through establishing an identity, establishing ground rules, determining how the team collaborates, and learning about the members that make up the team, we can establish a good foundation upon which to build our agile team.

A friend and colleague posed the following question via a text message:

What are the leading indicators that a program increment or team will not deliver on their commitment? What metrics would you gather to prove them out?

Before I dive into my thoughts around this, let’s setup a couple of assumptions. First, let’s assume we have a Scrum team that is following the Rules of Scrum. But along side that, let’s also assume we have a team that follows the spirit of the Agile Manifesto. I talk more about how I stand up a new team and my ideal relationship between the Agile Mainifesto and Scrum here.

With a Scrum Team, their commitment to delivery is to their Sprint Goal. While they forecast the stories they will work on and try to complete, they still commit to delivering their Sprint Goal.

When a Scrum Team works in a Program Increment (most likely as part of an Agile Release Train in a Scaled Agile Framework implementation), the team also commits to delivering Program Increment Objectives, or PI Goals, statements that summarize the value they intend to deliver.

So how do we measure if a team is on track toward delivering Sprint Goals and larger Program Increment (PI) Goals?

Is a team on Track to meet their Sprint Goal?

There are a few indicators we can use to help us understand how a team is progressing towards their sprint goal. However, none of these are perfect. All that they allow us to do is to ask better questions.

Burndown (or Burnup) Chart

Burndown or Burnup charts have long been a powerful tool for agile teams to inspect how they are tracking towards completing the sprint. A typical Burndown or Burnup chart tracks how the team is progressing towards completing all of their stories within a sprint. If the team is on pace to complete all of their stories, that is a good indicator of success. Conversely, if the team is not on pace, that may indicate a problem.

However, there are 2 problems with Burndown/Burnup charts. First, despite efforts to complete work early and often in a sprint, many teams tend to complete more stories the last couple of days in the sprint. So, a team that appears to be off track might surprise you and complete everything.

Second, and perhaps more importantly, the Burndown/Burnup chart does not track completion towards the Sprint Goal, just the items that make up the sprint. The Sprint Goal might entail completion of 1 or all of the stories in a sprint, or somewhere in-between. So a team that completes just 1 story might indeed achieve their Sprint Goal, if that story was all that was necessary to accomplish the goal.

Injected Work

$#!& happens. An emergency issue occurs in production. A user story was missed. An important bug needs to be addressed now. Whatever the case, a team that operates in an agile fashion has to respond to change and bring in work into the sprint. We call this “injected work”.

Focus is one of the 5 driving values of Scrum. Injected work will force a team to lose its focus, which can jeopardize the Sprint Goal, the stated focus for the sprint. While tracking Injected work does not correlate directly to a team completing their goals, it can indicate trouble lies ahead.

A metric of a bygone age may also be useful here: defect rates. In a world of waterfall projects, Project Managers would track defect rates as an indication of progress towards completing a release. The idea being that once the level of defects found level off and no more critical defects exist, a project is ready to release. For Agile teams, tracking defect rates may also be useful, as this indicates quality of the product. Products with poor quality will likely have larger amounts of injected work, have higher technical debt, and cause teams to run into more issues as they progress towards their Sprint Goal.

Is a team on Track to meet their PI Goals?

Many of the metrics for a Sprint Goal can also be applied towards larger PI Goals. Burndown charts can be particularly useful, when the team identifies the critical path.

Track the Critical Path

Not all stories that a team plans in a Program Increment are critical to the success of the PI Goals. Some of them are simply “things the team needs to do”, like update code libraries, adhere to a new legal requirement, or address technical debt. But, there are other stories that are crucial to the success of a PI Goal, and these stories lay out a Critcal Path to the teams success. If we ask the team to identify this path for us, we can track it via a burndown chart and see their progress towards the end result.

Like any other metric we’ve discussed so far, this isn’t perfect. It’s possible for the team to identify new stories, causing the critical path to change. Depending on the goal, it’s also possible for the critical path to be completed, only to find out that we made incorrect assumptions along the way.

Actual Velocity vs Planned Velocity

When planning a Program Increment, the team plans stories based on their Planned Velocity, or the velocity they expect to achieve based on what they’ve accomplished in the past. By tracking the velocity the team planned to achieve vs their actual velocity, we can see if the team is accomplishing more or less than they anticipated.

Of course, by now you’re expecting me to state a negative to this approach, and this time it’s a big one. Just because a team is accomplishing a lot of work, it doesn’t mean it is the right work to achieve the Sprint or PI goal. It could be made up of injected work, technical debt, or simply stories that do not align with the team’s goals.

One Radical Idea

As we’ve examined a number of metrics, there have been issues that arise with each of them. So what is a team, train, or leader to do to tell if a commited goal is still achievable, in jeopardy, or out of reach? One radical idea is also the simplest: ask the team. In SAFe, we establish commitment to PI goals based on a confidence vote from the team. The team are the ones committing to the work and the ones closest to it. Thus, they should be in the best place to gauge whether the goal is on track or in jeopardy.

One Scrum Master that I work with asks the team for how confident they feel they can achieve the sprint goal at the end of a stand-up midway through the sprint. The team votes 1 through 5, and when a team member votes low, she asks what can be done to increase the teams confidence in reaching their goal. This is self-organizing teams in action!

Concluding Thoughts

We’ve discussed a number of different metrics. Each of them have their place, and can help you understand how a team is progressing toward their goals. However, all that these metrics do is allow a team, train, or leader to ask better questions. A team may be tracking perfectly towards their goal, but one missed story could cause the goal to be missed. Conversely, a team could have horrible defect rates, lots of injected work, and a poor velocity, yet still achieve their goal.

Ultimately, the team doing the work will have an idea of whether the goal is achievable or not. Teams tend to be overconfident, but that is where I see the value of metrics. Bring in metrics to challenge the teams confidence, but when they are still confident, leave them to the task of completing the goal. And if their confidence was misplaced, let’s ask why we were overconfident, so that next time, we can do better in achieving our goals.

I was in Elementary school, perhaps 4th or 5th grade, when I came across an interesting book in our school library. It purported to teach the reader how to make their own computer games. Using some derivative of the BASIC language, it provided tutorials and the code to do various jokes and simple games. I recall specifically one program that asked the ‘player’ to point to their head and say the abbreviation for mountain (which is MT) three times. Then, after a few seconds the computer program would print out ‘It sure is!’, as it had duped the player to saying their head was empty out loud.

And while it would be cool to say from that day I was hooked at writing computer programs, the truth is a bit different. Sure, I wrote a few dozen programs as a kid, but by the time I was a teenager, I had moved on to other interests until my senior year in high school, where I decided to take a programming course. This class was also based in BASIC and I took to it like a fish to water. It felt like an old friend, but with age came a better understanding of what I was telling the computer to do. Where before stood insurmountable obstacles to my understanding were now gateways to a brave new world.

When I applied for college, I opted to major in History, but this did not last. Before I took my first class, I was a Computer Science major and never wavered from that path.

In 2004, in a graduate level class taught by my favorite professor, we learned about technical practices, agile development, and something called “Extreme Programming”. This exposure to XP was the first time that I felt like a professional software developer in college.

During my senior year though, I faltered. Through ignorance on my part, I missed the career days and questioned if coding was really for me. I didn’t start my first job until 2 months after college, and then it was a job as a QA Engineer. It was at this time I wondered, “Why am I coding?” and decided to start my first blog of the same name.

For me, coding started as a hobby, and I’ve always worried coding professionally would cause me to lose my passion for it.

But regardless, a year after graduating college I transferred to a role in Software Development and worked on many different projects for a number of years. Most of these were “waterfall” projects. But, in 2009, struggling to keep track of so many tasks, I discovered Kanban and embraced it for managing all that I was working on. I even went so far as to build a Kanban board app in Ruby on Rails and hosted it kanbanfordevelopers.com. In 2010, I moved on to a new job, where I worked with Kanban until 2013.

In 2013 though, an opportunity presented itself for me to be a Scrum Master for a Scrum team. I jumped at the opportunity, as at the time, it was only a part-time role. I thought this new role would allow me to ‘come out of my shell’ and learn to exist in an extroverts world.

But a few months later, the organization decided it was time to have dedicated Scrum Masters, so I reluctantly gave up software development for the first time.

About a year later though, I was bitten by the coding bug again, and jumped at the opportunity to be a split Scrum Master/Software Developer again. This time, I had the added challenges of working with a team that was new to agile, the organization, and was tasked with maintaining a legacy system where we had no one to ask how things worked.

And this time was fun. Perhaps some of the most fun I’ve had in my professional career. But I came to realize that by being a split role, I was hurting my team, so I gave up software development for the second, and perhaps final time. But this time, I did it knowing why I was doing it: the teams I coach can only be coached effectively if I give them my full attention, I stay completely neutral on technical decisions, and I use my coding powers for good and not evil.

So why am I NOT coding? So I can best coach, help, and grow the teams I work with.

A colleague asked me recently for some ideas on how to measure a team’s agile health. Like anything in agile (or in life, really), there are multiple ways to accomplish the objective.

One easy thing to measure is each team member’s satisfaction or happiness. This can be as simple as having each Scrum Master do a quick fist of 5 vote on happiness, with 0 or 1 being miserable, and 5 being very happy. The thing you have to be careful with this metric is that it doesn’t indicate an issue with a team. A low score could be due to an issue with leadership. Perhaps leadership has done something that the team is unhappy with. Perhaps leadership has set a team up to fail by placing people whose personalities just don’t go together. Or, perhaps the team is unhappy with themselves on how THEY are performing.

Mark Griffiths “PMI-ACP Exam Prep, 2nd Edition” suggests an interesting success metric for a team’s agile health - it boils down to 3 simple questions:

* Did the team deliver on what the customer wanted?
* Did the team leadership stay intact?
* Would the team operate in the same process again?

Unfortunately, this is a lagging metric and doesn’t allow you to pinpoint where a problem exists -it simply tells you if a problem exists. But, it’s simplicity does make it an attractive option.

A third approach is to present to the team the 4 values of the Agile Manifesto and ask each member to rate the team or organization on each of the 4 values. This will help you pinpoint where a team is unhappy, but if team members have different opinions of what the 4 values mean (and they will), you will get varying scores and opinions. But, this is pretty simple to do and you can track it over time.

A fourth tool for assessing agile health of an organization is this model called “Agile Fluency”. There are coaches who can come in and “assess” your organization, or you might be able to do it yourself. It’s an interesting model, but I haven’t used it myself. I’ve found more benefit in using it as a model for growing teams and generating ideas around how I can coach them to reach the next level.

The final tool and one that I’ve used for a while now is called Agility Health Radar. It’s not cheap… in money or time. It costs about $1,000 to become certified to facilitate the assessment and an on-going licensing fee to the tool. But this tool provides a clear visual on how the team feels like they are doing and provides them insight on how to improve.

The Agility Health Radar starts with a facilitated survey by a Certified Agility Health Facilitator. This survey lasts about an hour, and with the latest update, provides clear guidelines on how a team scores themselves in various areas such as “Generalizing Specialists”, “Predictable Velocity”, “Creativity”, and “Technical Excellence”. Once the team completes the survey, they then review the results as a team, discuss what they can improve, and raise concerns on impediments to their growth to their leadership team. These “Organizational Growth Items” are then discussed with the leadership team to be discussed and possibly resolved.

There are a number of ways in which an agilist can measure a team’s agile health. The approach you take will depend on your budget and time that you can invest into the approach. I recommend starting with asking the team how they feel they are doing on the 4 agile values. You can expand this to the agile principles, Scrum values, Lean-Agile values, or whatever else the team or organization values. Just like anything in agile, start small, experiment, and iterate.

How does someone get better at a skill? A new skill might require initial education, training, reading, watching, and thought to get to the point that the skill can be utilized. But regardless of a new skill or old, the only way to improve the skill is through dedicated time for practice. I can read all that I can find on improving my golf game, such as good swing techniques, or how to play various shots, but unless I practice, swinging the golf club or playing various shots, my golf game won’t improve.

But you might think you’ve reached the pinnacle of a skill and have no room for improvement. You’re like a professional at that skill, and professionals don’t spend time on practice.

Or do they?

Do professional athletes practice? They’re skilled at their profession, enough to put it on display each game. Do they practice? Of course they do! There’s always a move they could do better, be faster at, or understand the situation better.

Writing and designing software is a skill, a skill that we often take for granted. Once we’ve mastered a framework, library, development methodology, or tool, do we take time out to get better?

What we need is a method to practice these skills in an environment that allows us to refine and improve them. A series of software problems to solve, design, and code allowing software developers and testers a chance to improve in whatever framework, library, methodology, or tool they choose.

Put this all together, and you get the concept of a Code Kata - software problems that teams repeat to improve their skills.

Take some time out of your busy work week and try a code kata for an hour or two. And I challenge you to see if it improves your coding and designing muscles.

There are a number of resources on Code Katas. A few of these I’ve found include:

[http://codekata.com](http://codekata.com)
[https://www.codewars.com](https://www.codewars.com)
[https://github.com/gamontal/awesome-katas](https://github.com/gamontal/awesome-katas)
[https://github.com/pivotal/code-katas](https://github.com/pivotal/code-katas)
[http://www.codekatas.org](http://www.codekatas.org)
[http://codingdojo.org/KataCatalogue/](http://codingdojo.org/KataCatalogue/)

Good luck and happy coding!

When tackling a new project, feature, or application, it’s often useful to define a ‘minimum viable product’ or a ‘minimum viable feature’. The pure essence of this idea is to identify the minimum amount of requirements that produces a valuable and usable product. This ensures we focus on just a few features and deliver them quickly. Ultimately, we want maximize the value we provide, which means we may not implement all of the features we have planned. To truly maximize the value teams deliver requires a critical eye on requested features and a product team that is not afraid to say “no”.

While we strive for that level of rigor in our product backlogs, do we enforce the same level of rigor in our agile practices? As we add more teams to an organization and add more coordination points, we may be tempted to reach for some scaling agile practices, such as Communities of Practice or Scrum of Scrums. We may even reach a point where a scaling framework like the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS).

But we should hold ourselves to the same level of rigor with our organizational changes as we do with our product backlogs. That means we should aim for minimum viable scaling; the least amount of scaling we need to achieve value from it. That means we need to say “no” to some scaled agile practices and aim to implement the most valuable ones first. Our aim in our scaling efforts should be the same as with a product backlog: focus on what gives us our ‘biggest bang for the buck’ first.

Have you heard this one?

A man goes to his doctor and says “Doc, it hurts when I lift my arm over my head.”

Too which the doctor replies, “Then don’t do that.”

As coaches, we are asked to diagnose a team’s ailments. And while most of times the solution is the application of various agile practices, sometimes the solution is much simpler. Take for instance:

QA Engineers making heroic but stressful efforts at the end of a sprint to close out stories.
The Product Owner prepping stories the night before a Release Planning meeting.
The Dev team continually committing to more and more work that they stress over, pushing them beyond a ‘Sustainable Pace’.

All of these share one thing in common: stress.

In agile, if we’re stressed, then we are doing it wrong.

When stress on the team manifests itself, something in the Agile process or the team itself is wrong.

In the above examples, there are ways the team can work better that does not involve last minute heroic efforts by the QA Engineer, the Product Owner. The QA Engineers need to speak up to the team and work to resolve the problem that results in a number of stories being closed at the end of the sprint. The Product Owner could ask the team for help with prepping stories, as story writing and prep is something the team can do and owns. In the case of the Dev team working beyond a ‘Sustainable Pace’, they need to be coached on what this means and what an acceptable level of work to commit to looks like for them.

Emotions, including stress, are signs of how a team is functioning. Negative emotions, including stress, are signs that something is not working right, either with Agile or with the team.

What emotions is your team exhibiting and what are they telling you?

Wayne Gretzky. The “Great One”. Growing up in the midwest, I only had a passing knowledge of Canada’s favorite sport, Ice Hockey. But growing up, I knew of Wayne Gretzky. He led his teams to 4 Stanley Cup Titles. He was selected as Most Valuable Player 9 times. To be that good, no one could argue that Wayne Gretzky was knowledgeable about how to play Ice Hockey. I’m sure that is part of the reason why he tried his hand in coaching the Phoenix Coyotes.

But as a Coach, Gretzky had no where near the success he had as a player. After 4 years as a head coach, he had failed to take his team to the playoffs and had an overall record of 143 wins, 161 losses, and 24 ties.

Michael Jordan. In Basketball, he was a legend. During the 90s, he led the Chicago Bulls to 6 NBA Championships. He was selected as an NBA All-Start 14 times. He holds the record for the highest career scoring average at 30.12 points per game. After retiring, he became an owner in the Charlotte Bobcats (later renamed the Hornets) and took over basketball operations.

But, the Hornets never achieved great success. But they do hold a special record of their own. During the 2011-2012 season, the team won only 7 games out of 66, a .106 winning percentage, the worst winning percentage in NBA history.

So what happened? Why did Wayne Gretzky and Michael Jordan fail? Did they not know enough about their respective sports?

What these coaches forgot or neglected was the coaching part of a Hockey Coach or Basketball Coach. They were clearly experts in their sport (and in the case of Michael Jordan, perhaps far more than you know), but where they have failed is on the Coaching aspect of their job.

As Agile Coaches (or Scrum Masters who are asked to ‘Coach’ our teams), we have to remember what the coaching aspect truly means. Our Agile expertise is useless if we cannot influence, show, and persuade individuals and teams on the agile values and practices.

When we meet with other Agilists, we often talk about utilizing the latest Agile Practices, techniques, or remind ourselves of the values and principles. But, as you consider your own growth as a Scrum Master or Agile Coach, don’t forget to strengthen your skills as a Coach.

If you don’t, you might end up with a team with a worse winning percentage then .106.

Revisiting High School physics, the Second Law of Thermodynamics introduces the concept Entropy. Simply put, Entropy is the amount of disorder in a system. In any given system, Entropy can only increase over time, meaning disorder increases over time.

While the concept applies to Thermodynamics, you can see it at work every day. If you don’t dust your house on a regular basis, the amount of dust (disorder) increases. Roads age over time and form potholes that require patching and eventually, require the road to be re-pathed.

Development teams are not immune to the Trap of Entropy. If they are not actively trying to make themselves better, a team will move to disorder. This is one of the many reasons why periodic Retrospectives are so important; they help the team establish order and ensure the team is improving. Because if a team is not improving, the team is declining.

Fifteen years ago, at a ski resort in Colorado, a number of technologists came together to discuss the state of software development. Included in this meeting was Kent Beck, Martin Fowler, and Ron Jeffries, both proponents of eXtreme Programming. Also present were Ken Schwaber and Jeff Sutherland, both key early proponents of Scrum. Also present was Robert C. Martin, better known as Uncle Bob Martin, and several other technologists.

The Values and Principles they published after that meeting are still discussed today and seem as important now as they must have then. All of them seem to be universal truths of software development; all of them except one. For the longest time, I’ve struggled with the importance of the third value, “Customer Collaboration over Contract Negotiation”. As it is with all of the Values, this statement means that while there is value in the first item, in Agile, we value the second item more. Thus, this value states that Agile software development values Collaborating with customers over negotiating with them over a contract.

For consulting companies and contractors, this value is VERY important, as it sets the tone for interactions one should have with clients. But, how does this value apply to a company that directly hires and pays the software developers that design, write, and maintain their systems?

I would argue that this value should read “Collaboration over Negotiation” and simply do away with the nouns in the statement. In this new format, it means that while we may need to negotiate from time to time, we value and prefer to collaborate. For Agile Teams, this means that when they are working with stakeholders and end-users, they strive to collaborate with them on requirements, design, scope, and schedule. Instead of the business dictating a set date, we strive to have a conversation, a collaboration, where both sides strive to talk openly and come up with a plan that is realistic and attainable.

Within an Agile team, this means that the User Stories we use as our chunks of work are truly a promise to have a conversation and don’t boil down to a negotiation over what set requirements actually accomplish the story. We don’t always cry ‘scope-creep’ when the Product Owner asks for a small change; we strive to collaborate at how to create the best product we can in the constraints the Agile Team is working with.

Between team members, this means when we interact with our team mates, we strive to collaborate with them instead of taking a more adversarial, negotiation-esque attitude in our dealings with them. If we have a disagreement on the design of a feature or a disagreement during a code review, we strive to collaborate together instead of taking a competitive approach.

The power of the Agile Manifesto partly comes from the fact that it is still relevant to discuss in a fast moving industry 15 years after it was published. They apply to software development broadly, but in their broad scope, sometimes need to be scaled down to understand how they apply in the real world.