performing

Challenges in Applying Agile to Personal Life and How to Overcome Them

Posted on by

Health Benefits to Practicing AgileParticipants using agile methodology can gain personal health benefits and increase safety by applying some of the principles and practices of agile to their own well-being. Here are some possible ways:

Creating a personal backlog: A personal backlog is a list of tasks or goals that one wants to accomplish in their personal life. These can include lists such as exercising, meditating, reading, learning, etc. A personal backlog can help one prioritize and plan their activities, and track their progress and achievements.

Evaluate Progress in sprints: A sprint is a short and focused period of time, usually two to four weeks, where one could work on a subset of tasks or goals from their personal backlog. A sprint can help one break down their work into manageable chunks, and deliver value frequently and consistently.

Limit work in progress: Work in progress (WIP) is the amount of tasks or goals that one is currently working on at any given time. Limiting WIP can help one avoid multitasking, reduce stress and distractions, and increase focus and quality.

Seek feedback and collaboration: Feedback and collaboration are essential for agile practitioners, as they would help in improving one’s performance and deliver better solutions. Similarly, seeking feedback and collaboration from others, such as family, friends, mentors, coaches, etc., can help one improve their personal health and safety, as they can get support, advice, encouragement, and accountability for their actions.
Reflect and adapt: Reflection and adaptation are key aspects of agile, as they enable people to learn from their experiences and make changes accordingly. Likewise, reflecting and adapting on one’s personal health and safety can help one identify what is working and what is not, and make adjustments to improve their well-being. A good way to validate one’s performance is to mark down metrics at the end of a sprints as milestones.

Metrics that one should make note of during their personal sprint retrospectives

Improvement of physical fitness: One can use agile methods to set and achieve fitness goals, such as running a marathon, losing weight, or gaining muscle. One can create a fitness backlog with specific and measurable tasks, such as running a certain distance, doing a certain number of repetitions, or eating a certain number of calories. In the same way, measurement of these activities through digital fitness trackers, or digital body composition scales can further facilitate tracking via apps. One can also reflect and adapt on their fitness plan, and make changes based on those results.

Improve mental health: One can use agile methods to cope with stress, anxiety, depression, or other mental health issues by creating a mental health backlog with tasks that look to improve their mood, such as practicing gratitude, meditation, mindfulness, or positive affirmations. One can also work in sprints, where there’s focus on completing a subset of tasks within a fixed time frame, and track progress and well-being using tools such as journals, mood trackers, or apps. Other types of feedback can come from therapists, counselors, or friends, who can provide professional help, advice, and tips.

Improve personal growth: One can use agile methods to pursue their passions, hobbies, or interests, and learn new skills or knowledge by creating a personal growth backlog of tasks that can help them grow as a person, such as reading a book, taking a course or degree, learning a new language, or playing an instrument. The use of sprints can provide focus on completing a subset of tasks within a fixed timeframe, and track weekly progress and learning from tools such as quizzes, test results, etc.. Additional feedback and collaboration from others, such as mentors, teachers, or experts, who can provide feedback, guidance, and inspiration while providing proper ideas on how to reflect and adapt a personal growth plan, and make changes based on outcomes and feedback.

Like any step toward improvement and gaining any form of benefit, starts with a plan, and putting the types of ideas mentioned above into action. The best approach is to just start jotting ideas down or keep them in a physical or digital notepad, and once there’s at least five to ten ideas on what to improve, it’s time to put them into action and be consistent in applying oneself to the goal.

Automation is Key to Agile Implementation

Posted on by

automation-key-agile-implementationWhile most of us in our day-to-day would typically adapt to change whenever possible, it is very likely that we mindlessly have too much to manage. This is why automation is key to agile implementation. With a mindset to find ways for automation we promote a rhythm to the workflow, the process, the communication, etc…

Agile Ceremonies and built-in automation

When we look at the agile ceremonies overall there’s a flow that we can say exists, for example: (a) scrum or standup calls should take place at the same time every day, (b) sprint planning, sprint reviews, and retrospectives all take place on days that everyone has already preset, or (c) sprints should usually keep the same duration of weeks from sprint to sprint. We may ask ourselves, are these times and dates just a random practice (or requirement) of agile? The answer is no, not necessarily. There’s a reason behind all of this.

Keeping it Simple

While you may look to adapt to change throughout all the times of the workday, it is best to make the repetition as consistent as possible. This is similar in concept to what Einstein or Steve Jobs wearing consistently same clothing every day. This is just an example to make the point, but somewhat of an interesting revelation for those who are looking to simplify their day. For some we may think this “clothing” example is a little extreme, or irrelevant. Fair enough, this would be extreme in most cases. But when we are looking at our work environment, this principle makes a lot of sense for those who want to just concentrate and make decisions on what matters most. Putting in place what doesn’t matter so much, leaves time to make decisions that do matter. This in itself makes a lot of sense.

Consistent and Regular Adaptation

With reference to automation in the workplace, we’re not referring so much to setting up your schedule or planning in advance, although this is definitely a good habit, and better than not having any at all. We are referring specifically to having meetings, code reviews, or testing done in a way so that the agile team doesn’t have to constantly think about when it needs to happen. As an example, think of this question: What do you foresee being a problem if scrum meetings change times every day? It’s obvious, the team members will most likely be late as they try to figure out what time the meeting is at, or they missed it, and therefore all that time is just wasted when it could have been used more wisely and effectively. Some may even think, that “this inconvenience is minor,” but if you add that time up over a few sprints, you may be shocked to find out the cumulative amount isn’t as minor as you may have thought. Others may think, “this is just the normal workday or workweek,” and that it’s expected. However consider the advantages of setting this automated “rhythm” so that all that is less important is already out-of-the-way, and all the more important ideas and decisions can take place without distraction or resistance.

Admittedly, finding ways to improve a process and simplifying it in a way that is conducive to automation can be tedious, but once it’s in place, it does save a lot of time in the long run. More important than time, is the quality of the decisions and thought process that will come out of it. Think of it like a slow blockage that is eventually unclogging and allowing for a release of free-flowing ideas and productivity. Look to your sprint retrospectives to point out where areas of automation can be of benefit. You may already have some in place, but that should not stop an agile team from finding others. Incrementally and over time you can automate processes infinitely, but certainly it’s best to prioritize them where the benefit is worth the effort.

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of Idea go at FreeDigitalPhotos.net]

6 Main Reasons Why You Must Identify Backlog Item Dependencies

Posted on by

6-main-reasons-must-identify-backlog-item-dependenciesWhen creating and grooming a backlog in an agile project, it may come as no surprise that there is a constant need to manage it throughout the product’s lifetime. Common expectations from those who come from the waterfall mindset, is that you would just set up a backlog and the rest should take care of itself. But as you will eventually find out, you must identify backlog item dependencies.

The reality is that the moment you create the first backlog item, metaphorically it becomes a living organism. Many may think that the most challenging part of the backlog item, would be to fully define and estimate it. It certainly is one the earliest challenges in the backlog definition phase. However, it is important to consider, that with each additional backlog item that is created, there is an increasing need to consider inter-dependencies between all items. Not a daunting task if your list is limited to 10 or 20 items, but what about a typical project where there are over 50, 100, or more items.

Without putting the carriage before the horse, it is important to consider those backlog item dependencies initially with a backlog roadmap. Then it is also necessary to make it an absolutely regular activity to take on when backlog grooming. Below we identify the many reasons why backlog item dependencies need to be identified and linked to their co-dependent items.

1. Reduced Overall Project Risk

One of the main reasons why projects fail, is that there is no planning or overview of a roadmap before starting. Certainly, an agile project will prevent most of that with the regular sprint iterations and planning that happens before each is ready to start. However, what we are referring to here is more about consideration of what needs to be built, the moving parts, before all pieces of software or product can be put together. As an example, you can work on the roof of a house long before the house is actually built, but you eventually need to know that you need to build the foundation and structure before you will get to the roof installation. Further to that, you would need to identify the structural specifications (dependencies) to know that the roof will fit when the time comes to finalizing the house.

2. Value-added Efficiencies in Process Workflow

When your project is in mid flight, the last thing you want to get stuck with is realizing you just randomly selected some backlog items that don’t make sense to be in the current sprint. In the worst of cases, you would likely just leave it out as part of the grooming process. But on the other end, you would want to avoid idle time mid-sprint realizing that there were a lot of items that could’ve, should’ve, or shouldn’t have been there to begin with.

3. Facilitation of Priorities

As you identify dependencies early on in the project, the priority of all backlog items naturally present themselves. Like a seemless puzzle being put together from top to bottom, relating backlog items to see if there are or aren’t dependencies is tedious at first, but it becomes easier to balance as the software or product is being built.

4. Early Elimination of Blockers and Time Wasted

On a day-to-day process, through scrums and standups, a well groomed backlog allows for all team members to avoid getting stuck on blockers. Some blockers are inevitable based on the circumstances of the development process. But there can easily be blockers present on some aspect that could have easily been prevented, i.e. environment availability for a developer who would like to commit their code. Some blockers can have workarounds, but inevitably, the longer it is blocked, the more likely there will be time waste later on.

5. Proactive Conflict Resolution within Teams

When the teams gets to see the benefits of dependency identification, they will go on to assure there is regular backlog grooming almost intuitively. Each member’s best interests will gear toward pro-activity so that there is the least amount of conflict. Further to this, the team will be better prepared to resolve conflict should there be at any point. This is mainly a result of “lessened” levels of conflict. 

6. Increased Morale within Teams

As a direct result of lessened conflict, there will be heightened synergy among teams. They will have a higher tendency to gel together and get along. Effectively, this will prevent turnover and burnout with members of the team. Low turnover means that the team stays intact over long periods of time, and they benefit from not only being at the performing stage of team synergy, but also from the experience of working together for long periods of time. This benefit is irreplaceable and highly valuable.

Keeping an up-to-date backlog certainly has it’s benefits, but as we can see, keeping specifications up to date is not necessarily all about updating scope or tasks, but also continuously identifying how they are all tied together.

[Image courtesy of tigger11th at FreeDigitalPhotos.net]

 

Joining an Agile Team? Know Your Personality Type

Posted on by

joining-an-agile-team-know-your-personality-typeThere’s an interesting thing that happens when anyone joins a company, or a new project. The thought of an Agile Team Personality Type, its effects on team dynamics, and getting to a state of performance, gives another indication on how fast everyone will reach that state. Depending on the workplace culture, it is easily assumed that everyone joining or about to work on a project is going to be competent, knowledgeable and a contributing member of the team. This is sort of like a “honeymoon phase.” What we soon discover that this initial impression will eventually change, sometimes for the better, and possibly for the worse.

Why are Personality Type Considerations Important?

Human nature will indicate, most of us have a tendency to give the benefit of the doubt to a stranger at the very beginning of a relationship. After all if it was any other way, relationships would never exist. What we tend not to do, is think of our personalities with regard to others we are interacting with. Further to this, we don’t normally think of the other individual personalities with regard to their compatibilities to ourselves and to each other. The good news is that this one consideration can accelerate synergy and performance on many levels.

What Types of Personalities are There?

There are many theoretical personality types, some ranging from 4 (four temperaments) to 16 personality types (Myers-Briggs). Some debate on which are better, more accurate, or more thorough. Most individuals think that others are like themselves at the beginning of a relationship, after all, who do we know better than ourselves? They don’t think about personality types, for example, most will think “this person is more or less like me” until the relationship develops. Later on they think about the relationship as “this person is more or less like me, but (adding exceptions).” Eventually it ends up being “this person is not like me” or “this person is a lot like me.” This would be the natural progression. But it’s the long way. Thinking about personality types of others (and yourself) up front and early on in a group relationship will empower you to know what is the best or worst expectation to come out of a team member, either individually or as a whole.

Knowing Personalities: A First Step Toward Leadership

The irony in some projects is that we tend to get caught up in the risks that could prevent the project from being completed as per the budget, timeline, or scope, but it’s taboo to think of the risk of the varying personalities that are interacting in the project. Some are compatible, and others not. But what we should stop and think about is, what actually makes a project unbearable? Is it a team working together to overcome problems? Or a team complaining about who is responsible for those problems? Knowing why this is a tendency through personality types, can allow you to take a step back, be a leader, see things outside the box, and then make the necessary preventions and adjustments.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

5 Signs Your Agile Team Roles Might Be Falling Behind

Posted on by

After a couple of weeks, your team has undergone a couple of sprints. As an agile coach, scrum master, or team member you start to wonder if there are any signs that the agile team roles are performing up to par, or better yet, if there are tell-tale signs that your team is likely to under-perform in the long run.

Below are some distinct signs that you need to look out for:

1 – Velocity is fluctuating and unpredictable

The point behind tracking and managing velocity is to expect that eventually the velocity will stabilize at some point. This will go hand-in-hand with being able to make decisions on how many remaining sprints can be used to eventually complete the prioritized items in the product backlog, or how many points will be used for planning the subsequent sprints. If the team members are being pulled in and out of external assignments or multitasking on multiple projects, it would be expected that velocity is not going to stabilize any time soon. This type of issue can be rectified if the scrum master role or agile business coach point out to team members that they should remain exclusive to the one project being measured.

2 – Scrum and standup durations go off topic and outside timebox period

In many circumstances, we tend to go off topic on meetings where the members involved lose sight of the purpose or agenda of the call. If everyone is stuck on trying to resolve an issue on the scrum or standup, there needs to be a clear signal to all, “make a note of the issue,” and the respective members close to the issue can work together to help resolve it after the meeting. As a self-organizing team, all members should eventually realize that the scrum/standup meeting is not about problem solving, nor is it entirely about status. Some agile practitioners do not realize that the meeting ultimately is about commitment to the team. The update comes when saying what was done yesterday, but what will be done today, given there are no blockers, is the commitment. Beyond that, there should not be any reason why a scrum/standup would take so long.

3 – Overly dependent on fill-in roles

5-signs-agile-team-roles-might-be-falling-behindThis issue comes with improper planning, lack of agile training, or missing skills assessments. It becomes a very awkward situation when large gaps in skill sets occur in the project. This may also be a result of disengaged stakeholders that may have misrepresented their requirements early on. The main idea behind having a self-organizing team is to be sure they can cover each other’s skill gaps in a general sense, but if there are huge gaps, i.e. there’s nobody with agile business analyst capabilities, and project requires one, there certainly needs to be a discussion around why that position isn’t filled right from the start. Other issues start when agile team members are partially assigned to another project at some point mid-flight in the project. As an example, if a Product Owner is not fully engaged, the backlog ordering and prioritization will suffer. This may put a strain on the entire team to fill in for. Since the Product Owner is the one who knows the business values of the features to be ordered in priority, it’s not necessarily an easy gap to fill. Someone needs to step in and take over that role on a full-time basis so that the backlog is groomed effectively and with the expectations of the stakeholders.

4 – Loss of transparency and hidden agendas

There may be instances when some members are no longer motivated, perhaps because of personality incompatibilities, or superiority complexes. Obtaining an agile mindset is not easily achieved by everyone, but there are some that fall back into command-and-control mode, or don’t feel  the need to attend agile courses. In doing so, this may bring about the sense that some team members are trying to “one-up” the other by keeping information hidden from others until the last possible minute, and catching everyone by surprise. Nobody would want to find out toward the end of the sprint that a particular feature can not be implemented, if that information was actually known at the beginning.

5 – Repeated anti-patterns that were identified in Retrospectives

As you come to the end of a sprint, the team’s opportunity to provide continuous improvement feedback is driven in most part by the retrospective session. This allows everyone to identify what they did that went well, and didn’t go so well. Further to this, there are categories of instances that should be identified as what to “continue doing,” “stop doing,” and “start doing.” As you might guess, the hardest part to do out of those three instances is the “stop doing.” We can see even in our present lives, that habits are hard to break, and in most cases we like to keep the good ones, but really try hard to get rid of the bad ones. Over time it may be normal to see that certain bad habits within the agile team continue through multiple sprints, however if you’ve reached past your third or fourth sprint with the same habits continuing forward, there may need to be some further process analysis to zoom into why these ineffective workflow processes or habits have not been extinguished. A simple and fast way to get to the root of most issues, is through activities such as asking the “5 Whys” or drawing (and populating) a Fishbone Diagram.

What to Expect From the Team

The agile working team is one that learns and innovates over time. If everyone is there only to keep up with the status quo, the team will inevitably under-perform, too many negative issues will be left unresolved while leaving no time to address value-added tasks. The team should be engaged right from the start, with ample opportunity for buy-in from each member. If there are doubts being raised early in the game, that might be normal, but keeping those doubts on the radar, and perhaps even asking the product owner to add them to a risk-adjusted backlog (no matter how ridiculous they may seem) can provide some great benefits over time.

[Image courtesy of iosphere at FreeDigitalPhotos.net]

How to Recognize Team Synergy in Agile Teams

Posted on by

Ok, so you’re about to start your project and you look toward your resourcing department to get new team members to join the group. You realize quickly, that you want to be sure you can foresee whether or not your colleagues will allow for creating something great and interesting. As you proceed with introductions and discussions, you start to wonder how soon your agile team will reach its fullest potential regarding synergy and the related benefits of reaching that high point.

Team Synergy is NOT instantaneous

recognize-team-synergy-agile-teamsWe must consider that everyone can learn to get along and get the project from start to finish with a deliverable that all stakeholders expected, like a well oiled agile supply chain. Office politics aside, there will be those that have their own hidden agendas, clique mentality and those who will want to do things their “own way.” This of course means they are not team players, but I’m speaking to those who like what they’re doing and prefer to do things as a team. Fundamentally I’m referring those who are professional-minded.

What does this mean for an agile team even with a good set of skills and capacity to deliver? Stages that all teams must undergo over time, regardless of each member’s level of maturity or project methodology you use, it will happen in the same order as the following:

1. Forming: This is the initial stage, and it’s the easy stage. It simply represents the team members getting together, being formally introduced, and everyone getting to know one another.

2. Storming: This next stage is where everyone starts to flex and see what their colleagues are capable of, but also where boundaries are set, whether implicit or explicit. It’s where everyone identifies with their strengths and makes sure everyone knows what their area of expertise is. This evidently, is the stage where most conflict will occur, and as you might guess, is where everyone’s level of maturity will show up. So there will be resistance, and possibly group dynamics that will bend and stretch. A good recommendation at this stage is to get some good agile consulting, agile training courses, or participate in agile games sessions.

3. Norming: This is the stage where the “dust settles from the storm.” Everyone recognizes their differences, and moves to agreement whether pleasant or not, but they work to understand and trust each other’s area of expertise, despite disagreements in certain areas, they take on their roles within the group.

4. Performing: This is typically the final stage, and it’s where the team dynamics and synergy are at their optimal level. In comparison to all stages before it, this would be the fun stage, and it’s typically where you want to keep the agile team intact, motivated, and contributing. Soon after this stage, we would typically adjourn as the project ends. For the best interest of your customers, you likely would want to keep that team intact from one project to another, unless you’re willing to expect a period of disruption. Depending on how many members of the agile team you switch in or out, the impact and time to get back to performing will vary. The potential results gained from a fully functional agile working team reaching this stage is a considerable asset.

Getting There is a Challenge, Staying There is an Even Bigger One

Consider that all these stages are in constant flux, especially when new members are introduced to the team and it’s regardless of whether or not you following waterfall vs agile principles. Another important factor is the size of the team, the larger the team, the more channels of communication there will be and that increased complexity will extend the duration of those stages. Learning to identify each stage as an agile team progresses will help everyone to understand what types of agile solutions and outcomes to expect.

Another point we should not ignore, is the impression that we are in a later stage, when everyone has not entirely transitioned. That is to say, even if the team appears to be “performing” (something I like to call “pseudo-performing”), they may not have actually gotten past “norming,” possibly from the effects of a few bad apples, or members that just can’t agree to anything.

On a final note, these stages cannot be forced on a fixed or expected timeline regardless of whether or not you are considering waterfall vs agile, but they can be facilitated by an agile business coach, an essential part of an agile team. It wouldn’t necessarily be a formal note to the team saying “hey everyone, we’re in the ‘norming’ stage so let’s move on to the next stage.” Rather it would be along the lines of a statement such as “I can see our tasks are progressing well and there’s no major disruptions, everyone is in constructive agreement, we reached the ‘performing’ stage.”

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]