agile teams

Pros and Cons of Scaled Agile Framework (SAFe)

Posted on by

pros-and-cons-of-scaled-agile-framework-safe

There’s definitely a lot of buzz these days on the most popular types of Agile-At-Scale frameworks that would enable a company to scale for larger teams and varying company sizes. Everyone wants to go with the most popular one and assume that it’s the most effective one. We are providing an unbiased view of the pros and cons of Scaled Agile Framework (SAFe). Just note that a more popular framework doesn’t mean it’s better, or at least in the context of adoption and use, it might not be the best one for your particular company culture, size, situation, growth, budget, etc..

Is Scaled Agile Framework (SAFe) the Best for Your Company?

Scaling for agile implies that Scaling = Increase, Expansion or Variation in Size. That being said, it needs to be considered, what will be the amount and speed of growth as well? Not to mention, the budget and time required to sustain the adoption of the particular framework of choice. Below we explain SAFe and how it may or may not be best for your organization. We also take into consideration what may be the reasons for it’s popularity and growth.

An Unbiased SAFe No-Nonsense Assessment

The Scaled Agile Framework has evolved by far as one of the more popular of the frameworks. Created by an Agile pioneer Dean Leffingwell, this framework requires your teams to get certification through mandatory courses from a Certified Trainer (SPC and/or SPCT depending on the certification). Add to that the small “e” at the end of SAFe seems like a desperate attempt at an acronym just for the sake of making it a buzzword in and of itself. Does it come from the “e” in Framework? In any case, without the “e”, SAF wouldn’t sound all that nice from a marketing perspective, so most of us have just gone along with it, no questions asked.

Nonetheless, SAFe provides a well outlined Roadmap with a large variety of courses to get a better understanding of the multiple levels of scale. The types of courses will depend on the size and maturity of your agile teams within the enterprise (Essential, Large Solution, Portfolio, and Full).

With the entire spectrum (or as much as it possibly could be covered) of a scaled framework in an agile context, it needs to be outlined that in addition to the cost of courses, they also require annual subscription renewal fees, and much like the structure of software updates, will have major (x.1, x.4, etc.) and minor updates (3.x, 5.x, etc.) that a certified associate would need to maintain. That is as much an advantage as it could be a disadvantage. We outline those below.

Advantages of SAFe

  • Whomever is certified will need to make sure they have taken the latest exams and courses to be able to claim they have the latest knowledge on the framework. This also allows everyone to look forward to the latest and for those who have the time to update to take courses, read, and pass the exam, it is a great way to stay engaged. It is by far the most flexible and adaptable to an enterprise’s size and growth.
  • They do provide as much support as possible to provide access for members to a dedicated community and forum as a source of resources and answers to general and specific questions. They also have an app that can be downloaded to your mobile phone, tablet, etc..
  • This framework is here to stay, and would most likely be increasingly popular, adding to the fact that it has partnered (to some degree) with Atlassian through JIRA Align as a fully compatible tool. Those looking to use the JIRA Align tool, are in fact encouraged to become familiar with SAFe since it is almost entirely built on the same models and sub-framework models. This framework also supports in-person and/or remote agile teams when using tools like Atlassian’s Align, so this is further confirms that it’s definitely keeping up with the times.
  • Number of certifications are diverse, they include over 10 Types of certifications ranging from the very basic “Scaled Agilist” (SA) to the highly trained and/or experienced “SAFe Program Consultant” (SPC). They also include the certifications for the many roles that are present within the framework so that could entice new members to specialize in their areas of expertise.

Disadvantages of SAFe

  • If you haven’t learned about the latest version of SAFe, and/or haven’t passed the latest exams, you may have to deal with the fact that your knowledge can appear to be obsolete. As an example, you might have gotten the 4.0 level certification, but did not yet have the time to update to the latest 4.6. These updates also come within 2 years (or less) of each other, so this could present some indirect peer-pressure if your teammates have all updated on their end, as you will be the “4.0” in the room. Also, you have only a few chances to pass the exam, and if you do not, you will need to start paying for them. There also seems to be a missing component to the Agile Mindset per se.
  • You will need to renew your certification fee annually, but that is common with most all other framework certifications. It should be considered however, that you will need to budget almost automatically on an annual basis, that everyone who will be maintaining their certifications, will be dipping into the company funds to keep it (i.e. # of certified employees x Annual Renewal Subscription).
  • Given the structure of the training and maintenance of their certifications, you almost need to be an employee of a company implementing SAFe, either due to factoring the cost and or time to get training, or the minimum class size to make it worthwhile. However, this does make sense to some extent if you are about to embark on the SAFe journey. It would not be worthwhile doing this on your own with no company or team to implement it with.

Concluding Thoughts

Due to it’s vast coverage and all-round spectrum toward agility, it would certainly require more than a few Agile experts to implement this framework. It would also require all members to adopt it, let’s face it, there’s no “one foot in the door” approach, it’s all or nothing for this framework, as are most. But right out the door, you would need to expect at least the minimal budget for training for all members of the enterprise in order for a successful implementation, not to mention the cost of maintaining annual subscription fees.

The benefits certainly outweigh the costs of SAFe implementation, however, the costs should be considered ahead of time so that the benefits aren’t misunderstood for purely optimistic outcomes. You need to take the “good” with the “not so good” in these instances, and it needs to be determined as to what the immediate pitfalls are if the first attempts at gaining ROI or roll-out to full implementation are not as successful as expected.

The Agile Mindset And Why It’s Important

Posted on by

agile-mindset-why-its-importantWhat Is an Agile Mindset?

In the agile community, many newcomers have not yet adopted the Agile Mindset, and most don’t actually know it exists. They’ll see Agile as something they’d like to use as a tool, process, or methodology. But that is like comparing someone who wants to play a video game without getting into the story-line about what the actual game is about. Surely that will not prevent someone from playing the game, but their advantage compared to the rest of the players, will be heavily hampered. In order to be fully immersed in the experience, one must consider that there are others involved in the game as well. Some may also be better (or worse) than others in some aspects of the game.

To keep a team performing optimally, all members should adopt a similar mindset to level the playing field and keep everyone engaged to handle high complexity. In today’s world, it’s important to consider that we have an increased level of complexity. We all are part of complex environments, whether we think certain situations are simple or not, and the more we are aware of that, we can better circumvent these issues when they come up in the future.

Why Is An Agile Mindset Important?

Agile methodologies are best suited to handle today’s level of high complexity. But for this we need to consider what “complexity” is? In our day-to-day, everything can be perceived as complex, even just the drive to our workplace, or having to debug a line of code. One thing we need to put in perspective is that every large structure or concept is typically built over smaller structures or concepts. With that in mind, we also need to consider that we’re being subjected to and we may quite possibly be bombarded by many smaller elements of one entire complex process on a constant basis. Sometimes it may appear that we’ve tackled the daily simple task, but in reality, it’s part of a month’s worth of seemingly non-related tasks. 

An Agile Mindset is not a silver bullet to being fully immersed in Agile principles. It is a formal setting for your mind that will open doors, rather than close them once you are involved with an Agile team. The level of complexity that we all face in our teams could lead us to thinking that some things are not possible, and depending on the mindset of that team, that could potentially bring everything to a halt if they are not prepared to resolve it collectively. If you think of a mindset as a switch, such that if any one person in a 5 to 6 person team is not switched “ON” to the Agile Mindset, they may stick out like a sore thumb. They might not completely jive with the rest of the team’s discussions. Although they may still perform well overall, their synergy to help resolve issues and deal with the system of a complex situation will be less likely.

How Does An Agile Mindset Help With Today’s Problems and Issues?

Once we see a situation in which all members of a team are switched on to an Agile Mindset, where they are working in a complex Agile environment, it can be more easy to see that problems get resolved quickly and more easily. An organizational structure could benefit from a more flatter one since all members rely less on a hierarchical structure, specifically one that relies on top-down delegation. When all members are sharing synergies and giving all their optimal levels of involvement, decisions are made more easily and become more self-managed, wherein everyone knows their respective part, external blame and distractions become less prevalent and overall processes become more streamlined.

How Do We Adopt And Develop An Agile Mindset?

Genuine openness and engagement from each team member is necessary for the individual parts to work as a whole. This is crucial and works like any moving parts in an engine. The moment a gear, cylinder or plug in an engine doesn’t do what it’s supposed to do, the rest of the engine will need to compensate, other gears will grind, and the engine as a whole will risk overheating. In this same way, an Agile team must be aware and conscious that there are vulnerabilities throughout their performance. Some vulnerabilities may be individual, and others as a group. This is why an Agile team, although it should be shielded from external factors that could distract from the current focus, should also be well informed with the necessities that could possibly enable the team to perform effectively. A perfect example of this scenario would be to have an Agile Coach on-board, but it is also possible to get relevant reports and analytics from members of the team itself. In general, a diverse team, diverse backgrounds in culture or language, either technical or business or both, are all areas that could promote discovery of hidden problem-solving or creative avenues and provide the best overall direction for an organization.

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

The Importance of Time Completed and Time Remaining in Estimations

Posted on by

importance-of-estimates-time-completed-time-remaining/One of the first things many team members on Agile projects lose sight of is the importance of tracking their time spent on their tasks identified in their Backlog Item. Whether it’s a User Story, Sub-Task, Enhancement, etc., logging hours spent is of absolute importance to make sure further Sprint burn-downs, velocity, and estimates will continue to reflect increasing accuracy. The tendency of some teams is to use their Backlog Items (in either of the forms mentioned above), as a scope tracker. However, time-tracking on a daily basis is of absolute importance.

How Your Hours Should Really be Logged

Once a backlog item has been completed, only then do team members log their hours, and it most likely ends up being the hours set in the original estimates. Not only is it best practice to log hours spent on your backlog items on a daily basis, but also to re-assess what the remaining hours are. Just because an item was estimated to take 16 hours, and you performed 8 hours so far, it does not mean 8 hours remain. Sure it would seem logical that it would come down to a simple mathematical equation, but it’s truly not what is meant by “Time Remaining!” So what should be put in Time Remaining? It’s really about what should be required to complete the task at the moment of logging your time mid-course. What that means in our previous example; if you logged 8 hours for a task that was originally estimated at 16 hours, you may come to realize, there’s only 4 hours left. It’s as if you are re-estimating or re-assessing what is left to do. A number that does not match what was originally estimated, is perfectly fine either from a downward estimate or an upward one (assuming it’s done correctly of course!). This is by far the best way to know if original estimates were done accurately, and gives team members a gauge on whether those estimates continue to be assessed correctly in later sprints. Better yet, if needed, the variance of estimation accuracy can be calculated as well.

When Time Remaining is Not Taken Seriously

The problem arises when developers mark down remaining estimates as a straight-line mathematical equation, since it would imply that all original estimates were done properly, and makes it impossible to weed out the estimation imperfections during Sprint Planning from Sprint to Sprint. The other issue that may happen is that there could be a skew in estimations since some developers will take their time to complete a task (if they see that they’ve completed it early), and then hurry their task, or worse, bust the estimates if the task was underestimated. From there, it may escalate to having only underestimated tasks as being incorrectly estimated. What that gives is a mix of underestimated, and on-time estimates. As you can see, when the hours are totaled up for that sprint, the skewed results give an impression that generally all tasks were underestimated, and the lack of transparency will make the team draw separate conclusions. This also affects your burn-down charts and interpretation of velocity, all the while the cycle of trust within the team is broken.

How This Helps Continuous Improvement

Seeing the above situation in a different light, if you were on a trip where the original travel time was supposed to be 10 hours, only to find out the ride is shorter than expected, you would probably want to know, right? The same would apply if it would be longer than expected. To make the point clearer, your expectations, and that of others depend on the transparency of what remains to be done on any development effort. This aids efforts for future estimations and weeds out any further potential to be disappointed.

The next time you may be faced with a seemingly obvious question “How much time is remaining?” it may need to be seen as “How much time is needed to complete the task?” It’s not just a simple math calculation. Remember that estimates are called “estimates” because there is a chance that they will not be “accurate.” Having those numbers accurately represent “time remaining” allows for the estimation process to get better and better, as the team looks back in retrospect and compares their estimations for future Sprint Planning sessions.

 [Image courtesy of lekkyjustdoit at FreeDigitalPhotos.net]

Agile Antipatterns: The Dangers of Groupthink

Posted on by

agile-antipatterns-dangers-groupthinkAs agile practitioners we are always looking out for the best interest of all stakeholders. We understand that the team is self-managing, self-organizing, self-(fill-in-the-blank…). Apart from being aware of the values and principles that make up the agile manifesto, we are also concerned that as human beings we have an unlimited propensity toward certain truths and abilities, but our ability to engage in antipatterns is somewhat limitless. Enter the antagonizing concept Groupthink. Notice it’s not spelled in 2 separate words or no hyphen to merit their joining. At first we may think there’s nothing to be concerned about this term, but with further investigation we realize that it’s not something you’d want for your agile team.

What is Groupthink?

Groupthink is defined as the consensus or directions that a group of people take when faced with a decision. It stems from anything on the fear spectrum such as intimidation, or even just plain indifference. When stemmed from intimidation, the minority members may feel like they would need to agree with the majority so they could “fit in” or avoid being reprimanded. The proponent of such actions don’t appear to be so much about “ego building” but rather about “saving face.”

What Are the Dangers of Groupthink?

Therein lies the dangers of antipatterns what we have on a day-to-day. The old adage “the road to hell is paved with good intentions” rings in. How this happens to some extent is not necessarily with that one decision made on a particular day or particular week, but actually many decisions over many weeks, months, or even years. According to the Psychologists for Social Responsibility, Groupthink brings about the following inherent symptoms:

  1. Illusion of invulnerability –Creates excessive optimism that encourages taking extreme risks.
  2. Collective rationalization – Members discount warnings and do not reconsider their assumptions.
  3. Belief in inherent morality – Members believe in the rightness of their cause and therefore ignore the ethical or moral consequences of their decisions.
  4. Stereotyped views of out-groups – Negative views of “enemy” make effective responses to conflict seem unnecessary.
  5. Direct pressure on dissenters – Members are under pressure not to express arguments against any of the group’s views.
  6. Self-censorship – Doubts and deviations from the perceived group consensus are not expressed.
  7. Illusion of unanimity – The majority view and judgments are assumed to be unanimous.
  8. Self-appointed ‘mindguards’ – Members protect the group and the leader from information that is problematic or contradictory to the group’s cohesiveness, view, and/or decisions.

Does an Agile Mindset Prevent Groupthink?

Does removing a wrong statement from research make it right? This is the type of question we need to ask ourselves when we are on the path of continuous improvement. If we remove what is wrong in any environment, we could forget that it was identified later on. It is sort of like removing pages history from our past. We may likely repeat this behavior. Verbalizing would definitely be a start, either through a work-session, or by documenting it at some point. When something is verbalized by either an individual alone, or by a group of people, there is a process of recognition that builds concensus and buy-in. This is a very important of component of practicing with an agile mindset along with the concept of transparency. We need to be cognizant that we all know what we are agreeing to, or better yet we are not tricking ourselves to fit the ideals of our own personal agendas, principles or motives. We are looking at the bigger picture and are aware that we all collectively are deciding, committing, and taking the responsibility of those decisions. 

One of the most important elements in agile processes, commonly held in the Retrospectives, is that it helps promote the feedback loop and putting all cards on the table about the direction the team is taking. That is not to say that feedback does not occur in a daily standup, sprint demo, or sprint planning as well. The empirical processes of transparency should prevent Groupthink only to the extent that the team is willing to admit they are heading in the right direction, i.e. the team members could still all willingly pave the road to detriment if they so choose. But only difference would be that at least everyone knows they all agreed to it. When we have Groupthink, there is some obscurity about the true direction the team may be taking, in most cases transparency is intentionally hidden so that the issues and concerns will not likely come to light.

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of photostock 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]

 

An Agile Hybrid Approach – What to Consider

Posted on by

an-agile-hybrid-approach-what-to-considerMany practitioners and project managers look toward creating an agile hybrid approach by doing a mish-mash of waterfall with agile methodologies. However, what we are going to look at are the different agile methodologies and the ones that are actually compatible with each other. It must be said, that for any team about to proceed with tailoring different agile components, it is something that should be done with expert practitioners who understand the pros and cons of adding more than one methodology into practice. It is advisable that a solid team of expert agile coaches and scrum masters are present on such a team so that the evolution and benefits can be implemented effectively and safely for the entire team.

Agile Frameworks Compatible in Creating a Hybrid Framework

1- Scrum

Most members of an agile team know agile by way of the Scrum framework, but what most have yet to see is that although it presents a solid framework for complex projects, it could use the help of other methodologies. What we can take from Scrum however, is the concept of building backlogs with work items that get listed in priority. The second automatic component is the importance of a Product Owner who actually owns that list and ensures that they represent what the stakeholders will expect. This is done through prioritization of the backlog for the rest of the team so that a potentially deliverable product is completed and accepted by the stakeholders by the end of each sprint.

2- Extreme Programming (XP)

From this methodology we can gather the best practices for the development team including Refactoring, Test Driven Development (TDD), continuous integration (CI) and collective ownership. What we tend to see in these practices are the concept of work process that is conducive to the flow and efficiency of the work being done.

3- Agile Modeling (AM)

This methodology is usually considered an effective addition to most of the other agile methodologies. It has mainly two components: Modeling and Documentation. The Modeling component encourages best practices such as Just Barely Good Enough (JBGE), Architecture Envisioning, Lookahead modeling, Active Stakeholder participation, and Model Storming among others. The Documentation aspect covers the necessity of documenting continuously (not to be understood as documenting excessively), document late, executable specifications, and single-source information.

4- Unified Process (UP)

Over the years the Unified Process has taken on many forms, mainly the Rational Unified Process (RUP) from which it derived directly and sometimes is mentioned interchangeably. However, other examples include OpenUP, and Agile Unified Process (AUP). What needs to be considered is that UP is not just a process but an actual framework. What makes it useful is that it’s highly customizable with characteristics covering an iterative and incremental development process, architecture centricity and risk focus. From this framework we get 4 phases that are used for creating a project, namely in the following order: Inception, Elaboration, Construction, and Transition. Much of what is used in the Disciplined Agile Delivery (DAD) framework has adopted this but DAD has also added to this.

5- Kanban

From the realm of Lean practices, we get Kanban. This method framework builds on the concept of Just-In-Time (JIT) at its base, but it has many tools that derive from it, one of them being the Kanban Board. The Lean aspect comes with the concept of limiting work in progress to prevent waste. Along with that comes the concept of visualization of progress. With the use of Kanban, the level of product quality becomes optimal since all areas of waste (Transport, Inventory, Motion, Waiting, Over production, Over processing, Defects, Skills) are removed. Along with that, the high level of visibility of progress that the development team is something that is of utmost importance. As most who have practiced Agile will see, the aspect of visibility is a very important characteristic to creating and maintaining team synergy.

There are certainly other methodologies that can be put in the mix, but it must be considered that tailoring an agile hybrid approach is an art, not a science. That is to say, if key components are added from one project to the next, it will likely not create the same results for every project. There are many other factors that come into play, and would not simply be a matter of methodologies used, but also the variation of players involved, that is certain to change the project landscape at any moment’s notice.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

 

The Values of Being Self-Made For Agile Learning

Posted on by

the-values-of-being-self-made-for-agile-learningYou can never lose if you are determined to learn. Having the will to learn empowers you to know what to do, even if it is eventually to find out what not to do. Agile learning experiences allow you to do just that. To put this simply, you typically have 2 paths to learn, you are either told what to do, or you find out for yourself through your own experience on what to do, i.e. trial and error. With the analogy of getting burned on the hot stove, you can be told it is hot and will burn you if you touch it, but you will never really know what that means if you’ve never been burned before. Being told relies heavily on someone else for your growth, but what happens when that other person is not there?

Why is Being “Self-Made” Important?

Give yourself the ultimate test, ask yourself if what you’ve accomplished at any stage in your life was because you were told (or expected) to do it, or you did it because you yourself were trying to determine what to do. One path removed power, the other empowered you. We tend to get distracted by true sources of power, namely money. We strive to gain monetarily, but what if someone was given that source of power, but didn’t know what to do with it? It would go to waste wouldn’t it? Placed in the hands of someone who can’t think for themselves, it could even be used to do harm. This is where the term “self-made” comes into play. There are certainly much higher value to be considered a self-made person since it solidifies and confirms that you have gained through personal choices and experiences. This also means that a self-made person gains the added toughness of dealing with failure without being able to blame others for it. This builds character and if overcome, creates innate abilities to succeed and make further attempts to make things right.

Being Part of a “Self-Made” Agile Team

The structure of the agile team is one that should rely on the concept of being “self-made.” Why? Because learning is at its peak when you have a sense of self-consciousness. You are aware, you know that what you know is not enough. We tend to look at knowledge as finite, i.e. you took the course or made the grade so now you know everything there is to know about the subject. But that couldn’t be further from the truth. This is in part what many in the workplace dislike about those who claim they know everything. A team runs much more smoothly when the stage is set that they are all in in it to learn together and if they persist unconditionally, without pointing fingers and with compassion, there is a very high likelihood that they will succeed.

Wanting to Experience: The Key to Learning

When a group of people are proud of their greatest moments, they will likely stick together for the long run. Some may see learning experiences as a stepping stone to other new ways to learn, and others see it as a one step to being complacent. However if there is one factor that is certain from successful people is that despite all the experience they have, they refuse to stop experiencing and learning. This creates efforts that other like-minded individuals can be drawn into, and the learning cycle continues. The roles of the Agile team are there for a purpose, servant leadership being a huge part of it. We all think that the Scrum Master is the only one practicing that type of leadership, but that doesn’t necessarily have to be the case. Remember that the Scrum Master is not just a role, but also a role model, so it should not be left to one person to display specific and/or positive behaviors. Admittedly, it takes good synergy and team development before you get to a point of comfort and working efficiency within teams, but it is attainable and the benefits can be realized.

In order to get started with your learning path, ask one simple question “why?”. There’s a reason why children at an early age ask that question incessantly, as humans we are wired at an early age to want to learn, but then socialized into a system where we tend to stop. Go through your list of personal “why’s” and you may notice for yourself that there is something you may not have realized is stopping you from learning.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

 

Why Apply Agile Project Management Principles (part 2 of 2)

Posted on by

The following is Part 2 of the previous post regarding agile’s 12 guiding principles, and why they are important for agile project management. For Part 1, << click here >>.

7- Working software is the primary measure of progress.

why-apply-agile-project-management-principles-2-of-2Since we can’t use what isn’t finished, there should be no reason to consider it as “done” until it really is complete. In other project methodologies, specifically waterfall, we measure progress as an overall percentage and consider that percentage as a measure of completion. Working software is the only measure from which we are considering progress since what does not work, has no way of receiving ROI. It’s like giving someone credit for climbing a mountain at 90%, but they never reached the peak. Further to this principle, it also confirms that if something doesn’t work, why would you consider it complete in any way, when there is no real guarantee that it will ever work.

8- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This principle calls out to respecting the human aspect of agile team work. To maintain and motivate an agile working team we need to consider balancing the cost of development to the cost of human quality of life. It therefore promotes a work-life balance as being the main consideration to sustainability of the long-term “constant pace.” We’ve all heard of burnouts and the detrimental effects they cause to sustainability. When considering sustainability, it’s not just about what can be profitable over time, but also considering people-conscious limits. Some companies don’t set limits or are afraid of telling their customers that they have limits on how long developers will do the work. They see it as a competitive advantage to have developers work long hours during the week or over the weekend. While it may seem advantageous in the short-run, it is not sustainable in the long run, as it will cause the team to burnout, get sick, or leave.

9- Continuous attention to technical excellence and good design enhances agility.

While it may be tempting to develop code, or product just once and give it a thumbs-up, it may not necessarily mean that it is optimal. This principle covers the need to always look into best practices before, during, and after the code or product has been developed. Even when reaching completion, there’s room to improve and update as necessary, and the iterative process or attempt to gain workflow automation in agile, allows for this to happen if and when needed. In software we can refactor the code so that it runs smoothly, however it doesn’t imply that the original code should have been done to the standard of “just enough” to get by. While developing an element of code or product, you need to design it with intent of how it will provide value for the end-user, since poor quality in the end will cause higher costs and time wasted throughout the product life cycle.

10- Simplicity (the art of maximizing the amount of work not done) is essential.

When developing products, we tend to get bogged down by how many features the end product will have. Knowing which features will be needed as a minimum viable product can be tougher than it seems. However this principle also looks at “amount of work not done.” It promotes the concept of working smarter not harder, since working harder doesn’t mean there will be any efficiency built into the agile solution. Being able to prioritize features is the key element to maximizing simplicity, as most customers fall for the illusion that a product with many features is a product with built-in value. However, what gets lost in that perception is that there is no value if 70% of the features won’t even be used by the end-user once it’s released. Being able to prioritize is certainly a hard-to-acquire skill and activity, but it is one of the essential pieces to building simplicity.

11- The best architectures, requirements, and designs emerge from self-organizing teams.

This principle leads straight to the agile team roles, and their ability to be “self-organizing.” This drives the idea that the best can come out of a team that is highly motivated, and has a high level of buy-in. When the architectures, requirements and designs come from the team closest to the product, you will likely get a better result than if they were imposed on the team from an external or top-down approach. It therefore leads to more a pull type approach from the team rather than a push type approach from upper management. The dynamics and results from a self-organizing team allows for the team to take ownership and pride in the product they will produce.

12- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Continuous improvement is something that resonates throughout an agile project. This agile project management principle calls out to the necessity of improving constantly and frequently with the mention of “regular intervals.” This of course implies that there is an iterative aspect to the tuning of becoming more effective, however it is not limited to just one period of time. The use of agile retrospective events is certainly the highlight of reflecting over ways to improve what happened in the previous sprint, but this principle also doesn’t limit it to just that. We could almost say that this principle should be carried on a daily basis, and with the agile team looking to find ways to “tune” themselves regularly. When looking at it from a waterfall vs agile perspective, we must consider that most waterfall projects only do this once in the project management life cycle and likely at the very end, when it’s already too late to do anything about it. Regular intervals for tuning and adjusting behavior makes it more pertinent and effective since it will be addressed throughout multiple sprints and it will allow a chance for the improved adjustment to be implemented.

[Source for Agile Manifesto Principles: Manifesto for Agile Software Development]
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

Why Apply Agile Project Management Principles (part 1 of 2)

Posted on by

why-apply-agile-project-management-principles-1-of-2Many new projects seem to fail at the beginning, especially in hindsight, when looking back after months of development and product delivery progress. There have been many cases where agile projects did not even go over the Agile Manifesto which as most would should have been the first step. Beyond the 4 value statements from the manifesto, are the 12 principles that help guide the agile practitioner in keeping up with the 4 value statements. As we will see, all 12 were very cleverly worded and cover all angles that the agile mind would live by.

As part 1 of a 2-part series we will give further insight as to what those 12 principles are and why they are important for up-keeping in the context of agile project management principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (in non-software projects this would refer to product).

When we look at this first principle we see that customer satisfaction is the first thing that comes up, but that is not to say we need to do everything the customer wants outside of reason. This is why the second part of the principle mentions early and continuous delivery of valuable software/product. In all instances the customer relationship starts where ultimately there is a product to be delivered. If you note, the “early” part is also deliberate since it is essential to building the quick ROI for the client. The “continuous” part represents the iterative part about agile methods that allows for features to be built in with the value requested by the customer.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The requirements of an agile project are reflected by the Backlog (Product and Sprint). The backlog is the crux of the agile project methodology and workflow process, and is the basis of the work that needs to be done by the agile team. This principle of welcoming changing requirements in the format of a backlog allows for prioritization and re-prioritization at any moment within the sprint for the Sprint Backlog, and the Product Backlog throughout the agile project. Typically, the high level of transparency through daily scrums, and kanban boards, etc., allows for the agile working team to change requirements to reflect the ROI, resulting “customer’s competitive advantage” as needed and without the resistance that a project would have in a traditional waterfall setting.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The only way to gain return on a product is by confirming the results. Therefore the need to deliver “frequently” is tied to getting the most out of continuous delivery. This is part of the reason for preference to the shorter timescale, since that would provide more delivery cycles (iterations or sprints) and all resulting feedback loops from the customer and business. The other reason for preference to the shorter timescale is that it mitigates risks by allowing for developing time-sensitive competitive advantages (quicker time to market) of the software or product. When using lean tools the work-in-progress (WIP) becomes evident and quicker cycles prevent any wastes (so-called “muda”), and locks in the value of the delivered product.

4. Business people and developers must work together daily throughout the project.

When referring to working together daily this primarily refers to all agile team roles in the same room, face-to-face communications, and not so much on texting and emailing. Gaps in the daily interactions leaves room for unconfirmed value, and possible waste once business people and developers fall out-of-the-loop. The other key phrase is “throughout the project.” Some business roles, and developers may tend to fade in and out of the project if they are assigned to more than one project, and are spread thin throughout the course of the project. This leaves gaps in expectations and confirmation of progress when it is needed most.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

When a project gets started and is ongoing, we need to make sure we don’t get in the way of agile team members that are experts in their domain. This is where we build in the element of “trust” and leave them to do what they do best. Giving them the environment and support relies on the scrum master role where there is a need to protect the agile team from outside distractions, and help remove blockages when they appear.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The key here is that people are to engage in “people-friendly” situations that promote easy communication with the least amount of “out-of-context” risk as possible. Body language makes up about 55% of communication, and therefore represents the most powerful component when compared to 7% verbal and 38% tone of voice. Since email messages can take on a tone the reader chooses to interpret them by, a message may be interpreted as malicious where in fact it could have been completely benign. The other advantage of the face-to-face communication is that everyone benefits from osmotic communication whereby knowledge and information is gained from background discussions from fellow agile team members. This presents an overall advantage since it effortlessly keeps everyone on the same page.

For the second part of this section  << click here >>

[Source for Agile Manifesto Principles: Manifesto for Agile Software Development]
[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

10 Negative Sounding Terms Used in Agile Working Settings (But are not!)

Posted on by

10-negative-terms-in-agile-working-settingsSome level of confusion may occur with the use of certain terminologies, likely when a relatively new-to-agile member joins an agile working team. Let’s face it, we are living in a society that requires us to know expressions, abbreviations, or acronyms on what everyone is talking about as common knowledge. It’s certainly always best to ask the question up front, but for those worried about terms that typically come up in the context of agile projects, we’ve outlined some below.

Those joining an agile project will naturally learn quickly about every day agile terms that are not usually used in any other project context such as: scrum, sprint, retrospective, standup, etc., but what about the mention of some less familiar terms? Some might come up only a few times within a sprint or throughout the entire agile project.

Here’s a few examples of terms, that could raise some eyebrows upon first hearing them. You can rest assured most have a positive context despite their seemingly negative sounding words:

Burn-Down

The instance from which we use the term Burn-Down is with the Burn-Down Chart. This term has very little to do with burning anything down, at least not from the context of lighting something up with a flame or fire. The Burn-Down Chart, as an agile tool, gives a graphical representation of how much work is left to do in the sprint. The main component that is being represented is the amount of scope or story points completed, while giving a visual cue of agile team velocity.

Peer Pressure

Many of us started to hear the term Peer Pressure in our high school days. This brought about times of being pressured to fit in with the crowd by doing acts of stupidity, substance use, or criminal activity. Performing any of the acts would reassure acceptance for that member, but if not they would face possible rejection, bullying or humiliation. Peer pressure in agile working environments comes about more from the high level of transparency and visibility, than actual pressure from the agile team. The occurrence of peer pressure comes about when the individual reports their own performance and realizes that they may be stalling or slowing the rest of the team down. This could be a result of over committing, or just simply under-performing within the group. This typically would require the individual review with the agile business coach or scrum master role to see where or why they may not be a fit for the current team.

Burn-Up

Similar to Burn-Down, this term is also used when referring to an agile information radiator called the Burn-Up Chart. This chart can viewed side-by-side with the Burn-Down chart, but today most software applications can show them both superimposed for better understanding of progress. While the Burn-Down Chart will show how much scope or points being completed. the Burn-Up Chart shows how many hours are being used to complete the tasks. Both charts together will confirm whether or not estimates that we set in the sprint planning are on track or not.

Servant

For those who have taken on the Scrum Master role, they may learn eventually that their preferred form of leadership is that of “servant-leadership.” This in no way means being a servant in the traditional sense, but rather one of the most effective ways to lead by example. So the idea that a servant as a slave is very far from the intent. Servant-Leadership in principle is meant to serve others so that others can grow and become self-organized, rather than the opposite “command-and-control” approach to leadership that creates drone-like behavior from others.

Playing Games

Much of agile training and learning can come about from playing agile games. Typically when you think of playing games, it is thought that people are just horsing around, not being productive or wasting time. In the context of agile teams, it is very much encouraged to play games to get familiar with agile workflows, planning, iterative development, and team building activities. There are numerous and still new and innovative ways that agile practitioners play games to learn while adopting an agile mindset and principles.

Disruptive

When we think of the term disruptive on a day-to-day context, we tend to think of disturbance or distraction. In an agile context and mainly technological circles, disruptive commonly refers to innovation. To be part of an agile team that has created a disruptive technology or invention means that there has been a major advancement, so much so, that it actually brings the previous function, or use of the previously existing technology to obsoletion.

Pigs and Chickens

While working on an agile project, you may come across some farm animal terminology, specifically Pigs and/or Chickens. These terms are perhaps used less and less recently, but they came about from an anecdote that demonstrates the level of commitment of certain members of the team. The story refers to a chicken asking a pig to start a restaurant together called “Ham and Eggs.” The Pig answers “no thanks” since the Pig would need to be committed (since Pig has to be killed to make Ham), whereas the chicken would only be involved. This basically gives an idea of the different levels that certain stakeholders and agile team roles have in a project and how they should participate in sprint events such as the daily standup.

Pirate Metrics

For what is now being used as a part of agile metrics, you might think this has something to do with piracy. The term pirate metrics comes from the mnemonic term AARRR (the pirate rant) to remember the 5 key metrics to measure increasing revenue: Acquisition, Activation, Retention, Referral, and Revenue.

Fail-Fast

This concept about failing fast may confuse early agile practitioners since most people are told early and for most of their lives that failure is the opposite of success. Certainly this term can raise a sense of fear of failure and cause some resistance at first. The concept of Fail-Fast is a principal agile concept coming from inspecting and adapting. It is an approach to encourage early detection of failure, to be able to learn or fix quickly before sunk costs are incurred. In principle you would want to know if a project or product feature would fail at the beginning instead of reaching the end to find out it is a failure.

Empiricism

We’re not referring to empires and conquests with this term, although we can certainly get carried away and think that the project may take on that type of personality. Empiricism is mainly a scientific approach that requires a process to be observed and tested so that it can be considered universally effective.

Learning and Understanding Terms for Better Communication

There are certainly more of these types of terms that are used in Agile, but note that the best way to start learning, to keep learning, and to contribute to the discussions that come up in an agile project is by communicating with same type of vocabulary. There are already many factors that increase the risk of breakdown in the communication process, so we may as well get on the same page and know up front what common terms everyone may use use in the project.

[Image courtesy of photostock at FreeDigitalPhotos.net]

 

Agile Coaching and Mentoring – Wisdom Explained

Posted on by

If you’ve heard of situations where the “student becomes the master” and “the student becomes the teacher,” you might be asking yourself exactly what does that mean. Most think there is a distinct difference between the role of a teacher or master to that of a student. If there is one thing to consider is that they certainly cannot exist without each other. The main distinction behind how a student becomes the master is usually by the amount of practice the student had, and how he or she may then stand when compared to their own master when it comes to wisdom. This is also what happens in agile coaching and mentoring toward the agile team relationship.

Coaching and Mentoring – What is the difference?

agile-coaching-and-mentoring-wisdom-explainedMany consider the role of a business coach to be a mentor, and vice versa. A coach’s role is diverse and really depends on the background of the individual. Some might have specialized industry knowledge and experience in which they are taking part, but others might have process and/or procedural experience from a more diverse or general industry background. There’s no better or worse when it comes to those differences, however where there is a more distinct ability in question as to how much that individual analyzes, learns and gives back to those they interact with. That being said, an agile coach can be a mentor, and an agile mentor can be a coach. The difference there is how much time, dedication, and direction that takes place between the mentor and mentee, or coach and coachee. The mentor role might be better suited when the role is specific, i.e. a mentor for a developer is usually best suited when the mentee is also a developer. In agile circles, those lines are somewhat blurred and most of the agile coach role is taken on by the Scrum Master role. The agile business coach however, can be a separate role and is just as important as any other role.

When is the Coach a Student?

Remember when you were a student in class back in school, college or university? You were always thinking about how the teacher, separated by many years of knowledge, would always be the prime source of information, direction, authority, etc., on the class subject. We had the distinct notion that the teacher had taken on the role of the “all-knowing” in the classroom. But what we need to realize is that the teacher was also in an environment where they too were learning, and looking for answers themselves. Certainly many teachers had many styles, some better than others. Do you remember what made the great ones great? and the not-so-great ones not so great? What you may have realized is the level of involvement but also the level of in-depth conversation with the students. You may notice that the teacher although being a source of information and specialization expertise, was immersed in getting to know why their students thought the way they thought. They were learning too! This is very much the same way an agile coach and mentor would be with the agile working team and its members. The coach, just like the teacher, is also being a student to some extent. Why? Because they are in a state of constant learning, despite their high level of knowledge.

How Does Knowledge Transfer into Wisdom?

While in the student vs. teacher scenario, we can see that the student is the one always looking to prove their knowledge to their peers and teacher in a classroom. Many students might be motivated to attain a certain grade and use their knowledge to show everyone just how much they know. Wisdom comes when there’s a higher sense self-motivation, self-control and knowing when to use the knowledge, not just to get the grade, but also when to use the knowledge in and outside of the classroom. This also goes hand-in-hand with knowing that despite having increased levels of knowledge, nobody can ever know enough. This is the true turning point on wisdom. Much like power, it’s not about using power at all times, but when to use it that brings a better sense of refinement to any situation.

Creating Genuine Purpose to an Agile Coaching Philosophy

For those who become ambitious in their line of work, whether in agile team roles or not, there has to be purpose and thought to the “why” in their role. When ambition is driven by getting to the top of the ladder for popularity or for a sense of superiority, there is true lack of wisdom. The difference happens, as an agile mindset will show, when one’s purpose is to share with others. Much like a coach or mentor, they should not aim to become one just for the title, as someone in a highly regarded role that gains a lot of attention from all stakeholders in an agile organization.

[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]

10 Ways an Agile Mind Uses World Class Thinking

Posted on by

10-ways-agile-mind-reflects-world-class-thinkingWhen we discover what an agile mind can bring to its surrounding environment, it would very much resemble that of World Class thinking. Steve Siebold points out the many ways that Middle Class thinkers differ from those of the World Class thinkers. But what we noticed, is how similar World Class thinkers are to Agile thinkers. Many are very close to what you would expect as characteristics and personalities of an Agile team member.

Below are some extractions from Steve’s list of differences between the Middle Class vs the World Class. We’ve explained how World Class thinkers relate to that of an Agile Mind:

1. The Middle Class avoids risk . . . the World Class manages risk

Agile team members use tools and operate with a series of ceremonies and events that allow them to manage risk. They don’t avoid risk since they know that risk is unavoidable. They understand that having daily scrums, sprint planning, sprint reviews, sprint retrospectives, etc., will allow them to reduce risk and minimize (not eliminate) it as much as possible.

2. The Middle Class focuses on having . . . the World Class focuses on being

The difference being agile is actually “being” agile through practice and experience, not just “having” knowledge by reading a couple of books or attending agile training courses. An agile team mindset focuses on “being” because they are aware and conscious about their agile working environment. This means that it’s not just about switching their agile hats on and off. This is much like being an athlete, you don’t stop being a swimmer when you are not in the water. Also, it’s very likely your mindset reflects everything toward being the best swimmer you can be, in and out of the water.

3. The Middle Class sees themselves as victims . . . the World Class sees themselves as responsible

A self-organizing, self-managing agile working team knows that they are going to be responsible for the end result of their agile solutions. While they may have chosen not to become victims, the confidence they’ve built through team synergies allow them to meet their individual and group objectives without doubt.

4. The Middle Class is frustrated . . . the World Class is grateful

When faced with hardships and issues, the agile team knows that it’s sometimes part of their work. They depend on each other at all times and look to help each other out. Each member in turn, is grateful to be working side-by-side with each other and know that getting frustrated is wasteful energy. Part of this is through the scrum master role, or agile business coach, being able to protect and showing appreciation for each other as the team works through those issues.

5. The Middle Class is ego-driven . . . the World Class is spirit driven

The optimal agile team is aware that they are not a combined result of their egos. An ego is not what drives results, whereas spirit does. Although spirit can be broken, it can be set to greater sustainability over time. An ego is not immune to being broken either, and what we can learn is that it usually grows when it is given the wrong type of attention. Spirit overcomes negativity and is not fed by it. Growth comes with the combined spirit of all team members with results and authenticity of leadership that are much greater than those of an ego driven team.

6. The Middle Class is problem oriented . . . the World Class is solution oriented

When looking at building and creating agile solutions, the agile team knows there’s a problem to be solved. But they are not primarily oriented toward problems and how to fix them, rather, they are concerned with providing solutions. A successful product is not one that was made with problems to be fixed, but rather it is set on providing an optimal set of solution that are free of problems. The agile team working on a series of solutions is a lot more productive, since bringing attention to solutions increasingly expands into more solutions. In much the same way, bringing attention to problems creates more problems.

7. The Middle Class thinks they know enough . . . the World Class is eager to learn

Part of continuous improvement is knowing that we don’t know enough. This is where the agile team invests heavily in the use of sprints to not only develop a product, but also get to the point of retrospectives to learn what didn’t work, and finding new ways to work. The other way the agile team is eager to learn is by not resting on their laurels, and reaching new heights through practice and use of agile tools and agile games.

8. The Middle Class is boastful . . . the World Class is humble

When faced with praise, an agile team is humble and not boastful about their achievements. This is fueled by knowing that what was achieved was a result of the combined efforts of each individual within the group, and as a separate entity they are only a smaller part of the whole. The agile team also knows that being humble is a virtue and a strength that brings attracts others wanting to join that team.

9. The Middle Class denies their intuition . . . the World Class embraces their intuition

An agile team knows that they should embrace their intuition since it is a result of their synergies and attainment of high performance. The important aspect of attaining intuition is that it needs to be fed like a never-ending belief. The moment you deny or question the intuitive process, it switches back into over thinking mode. Over thinking will undo the intuitive process.

10. The Middle Class coaches through logic . . . the World Class coaches through emotion

Much like the world-class, an agile coaching philosophy will do so through emotion. An agile business coach knows that emotion is “energy in motion.” That relates to sensing where the agile team’s energies are and finding ways to bring them to balance. This is not just by trying to be a separate and logical member, but rather by being active part of the team and promoting the agile mindset. That would be the best way to know how each member is contributing to the overall performance of the individual and team.

[Image courtesy of Idea go at FreeDigitalPhotos.net]
[Source: Steve Siebold (177 Mental Toughness Secrets Of The World Class)]

 

5 Ways to Recondition a Waterfall Mindset to an Agile Mindset

Posted on by

5-ways-to-recondition-a-waterfall-mindset-to-an-agile-mindsetThe hardest part about attaining an agile mindset is undoing the beliefs and experiences of the past, especially if they were set over years and years of performing under a waterfall project methodology. Many would agree they had would have rather just started off with agile right from the start, instead of now realizing that experience must be undone. But like the expression says “better late than never.” Those who now have their eyes open to the benefits of adopting an agile mindset know there is no turning back. Or maybe that’s not as easy as it may seem. Undeniably, we are always influenced by our past experience and reprogramming our mindset to challenge our waterfall vs agile beliefs can come into play at any time.

Here are 5 ways you can recondition or progress toward an agile mindset:

1 – Keeping your priorities in check

If there is one thing that a waterfall methodology makes us lousy at is practicing our priorities. Since in waterfall we rely on a project plan with features set at the very beginning while expecting few changes later on, we lose the sense of why we are developing features later on that we no longer need. You may still see this in certain instances in agile project whereby the client still asks that all the original scope be delivered by the end of the timeline even when they may realize there no longer is any value to having some of those features. With an agile mindset all stakeholders would better understand that the project is a success as long as the prioritized features (not necessarily the entire product backlog) were developed within the agreed timeline.

2 – Knowing the difference between variable and fixed timeline

Referring to the previous point, in waterfall we agree on a timeline that we then may need to extend if there were any delays or unforeseen gaps that occurred. In agile we can fix the timeline if all stakeholders agree to priority of the features that they would like to have implemented. If all the top priority features are implemented by the end of previously determined set of sprints, it very likely will not need to have the timeline extended. That would also allow everyone to walk away with confidence knowing that the most important features were implemented. This basically means you need to adopt the concept of a fixed timeline and variable scope from an agile mindset, vs the fixed scope and variable timeline concept from a waterfall mindset.

3 – Avoid mixing project Gantt charts with Sprint and Kanban boards

Some of us might be tempted to report to many stakeholders and provide multiple types of reports in general. This could be internal auditors, PMO, upper management, etc. What you need everyone to realize is that there is no need to report in so many ways. In waterfall methodologies we tend to use “unlean” processes that give rise to the tendency to send a different report to each stakeholder in the hopes that everyone is reading them thoroughly. The truth is, some of these reports may be so complex, that most will look at them without a critical eye, only to be surprised that the report had raised many risks that surfaced. This is where having an agile mindset would come in handy. Mostly all stakeholders including the agile team are concerned about progress and the rate of progress. Keeping it simple with the use of Kanban or Sprint boards, and providing easy to read information radiators like Burndown, Burnup, or Cumulative flow diagrams will give a quick and informative idea on where it all stands.

4 – Dedicate yourself to agile training in all forms

We should not just learn about agile methodologies and claim we know all there is to know. Agile working tools evolve over time and it’s important to keep your ear to the ground on what the latest developments and ideas are from the industry experts and peers. Simply having a discussion with colleagues that have similar interests in agile implementation is a start. But as you would notice there are many other means to sharpening your agile mindset and agile tools. Participating in regular industry forums, conferences, agile training courses and annual tours can be highly beneficial and open your eyes to some concepts that were not previously discovered. Also picking up some books on agile, and reading a few from time to time will make sure you are feeding your way to improving your day-to-day ideas on how to promote and implement agile in your immediate work environments. Finally the scrum master role should be well instated, at some times with the help of agile business coach on board with your team. The agile coach in particular can gauge and see what can help improve what may already be in place, and furthermore stimulate ideas and get everyone elevated to an agile mindset.

5 – Keep asking yourself why certain processes and values have been adopted into the agile methodology

There are some in the industry that have a skewed idea of agile. Mainly because it’s something they may have heard someone else talk about and it just may seem to be a common buzzword. Those with a waterfall mindset may just think agile is a process, and will treat it as such. This will give rise to even more issues, as they may try to put sprints into place, and not really knowing why they are used in the first place. For instance, they might not actually believe in delivering anything beginning with the first sprint, although technically that should be possible. Also the duration of the sprint should be determined on how risky or how much change in the priority of the backlog items you expect to have. The main point here is to always be asking why certain processes exist and why they would be beneficial to the overall methodology. The other side of the coin is that some will implement agile in an environment where it isn’t even necessary, “if it ain’t broke, don’t fix it.”

Bringing these tips into consideration will help alleviate the built-in or innate experience that many of us have, especially if coming from a waterfall mindset. Also to be considered, is that nobody can switch on to an agile mindset overnight by reading an agile book or attending an agile conference. However, continuous learning, coaching and mentoring agility will certainly build on it.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Bringing Continuous Improvement to Project Methodologies

Posted on by

To those who have never seen agile at work, it would seem a bit odd to think of implementing it at first. Most people would see the vast levels of acceptance while bringing continuous improvement to project methodologies and think it was literally impossible to put into practice. But that is exactly what Agile is, practice. We live in an imperfect world, but we also have come to the belief that “practice makes perfect.” We’re not sure if that expression became so popular because it rolled off the tongue so well, or because practice really does make things perfect.

Perfection is unattainable, but reaching perfection is attainable. Typically when we’re practicing anything whether it be a sport, hobby, or process, we come to realize that we have a tendency to do it better and better every time we do it. Upon completion we use expressions like “note to self” in order to be sure we don’t make the same mistake again the next time. Or vice versa, we make sure we try another approach that is slightly different. It is exactly this line of thinking that fuels innovation. Much in the same way, this is how Agile project methodologies became what they are, bringing speed, synergy, and continuous improvement through regular practice.

Why Tailoring Agile Impulsively is Not Recommended

bringing-continuous-improvement-to-project-methodologiesAs some will find out eventually, we will not likely have a truly perfect product by the end of the first sprint, and there probably will be some revisiting or refactoring later on. However, with the use of multiple sprints, the team is aware that there will be goals to practice constant improvement of the existing processes along with a learning curve with each iteration. Whether it be the result of bug-fixing, improved design, or better material for a longer lasting product, it is that very system of agile project methodologies that allows increments to be built upon with regular feedback. As an example we can refer to the much ignored and under-practiced Sprint Retrospective. As there might be a sense of time limitations, to get things closed off and ready for delivery at the end of a sprint, some teams and stakeholders will make the sacrifice of skipping the retrospective to do what is thought to be more productive completion work. This is in fact a huge sacrifice, since the habit of skipping the retrospective in itself will wipe out the need or perceived need to do one for any future sprint.

An instated workflow process that does not leave time for a feedback loop, will likely leave one out for all future workflows. When this happens, danger presides and can only be undone when someone with a persistent agile mindset (likely an agile business coach or scrum master role) attempts to inform everyone that it needs to be added in. As you will likely notice, the “swimming against the stream” effect will come into play. It will be met with much resistance to change as we know most groups are prone to. It also will be met with much discouragement and heartfelt and time-wasting debate since there will be many who will be on both sides of the fence.

Setting the Record Straight

This makes the point, agile project methodologies, principles, and mindset are in place to function like an entire working organism, the events that are meant to take place are much more effective when they are all in plugged in. If they are removed or tailored, there has to be a highly experienced agile working team with an experienced agile coach that could pin point the possible downfalls of removing any aspect. Further to this, the highly experienced team would need to come to the agreement that if the foreseeable pitfalls were to occur, the missing pieces will be added back in, and with certainty of knowing that the pitfalls are being caused by the tailoring process itself, much like “trial and error” in experimentation. If the agile team roles are made up of fully inexperienced members, therein will be the ultimate risk and error just waiting to happen at which point there is no easy return even with agile training courses. This is where the self-fulfilling prophecy will come into place whereby naysayers will state that agile doesn’t work in the form of the much dreaded “we told you so.” Continuous improvement has a lot to do with accepting change. When sprints are completed and done properly over time and with additional coaching and mentoring, it becomes much more effective and seamlessly risk-free so that changes become more acceptable.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

5 Ways an Agile Coaching Philosophy Enables Agile Teams

Posted on by

5 Ways an Agile Coaching Philosophy Enables Teams to BE AgileAdopting an agile coaching and mentoring philosophy for your team can be very beneficial. Most believe that all that is needed to keep the agile team in good shape, is with the scrum master role. This may be the case sometimes, however the agile coach brings about much more than what the scrum master can do. This also applies more to larger scale teams where there are many scrum teams, and their respective scrum masters. The agile coach can take on the role of scrum master of scrum masters, but generally they can represent the organizational coach and mentor with the agile mindset. The title in most cases is not important, but the role itself is relevant to take on the following ways to inspire their teams.

1 – Showing the team how to be open

Many teams whether in their beginning forming or norming stage will need to build on their openness throughout their communication process. The agile coach would be there to explain and show the benefits of being truthful and communicating openly, without hidden agendas. Also they can help build on agile team roles that might be lacking direction or depth. Occasionally some roles haven been taken on without necessarily knowing the full extent that role may need to contribute. The agile coach can provide this additional support to getting those particular team members to acquire communication skills, and the benefits thereof, to their fullest potential.

2 – Modelling what it means give and earn respect

There is an old saying that “respect can not be bought, it must be earned.” This is saying rings true in all levels of an organization. The agile coach knows that they can’t go around asking that everyone respect each other, but they know that with proper demonstration of leadership, others within the team will get to see from the agile coach how the proper use of communication and demeanor truly benefits everyone through the interactions with the teams. By earning respect from their peers, not just by title, but actual use of meetings and personal interaction.

3 – Bringing out special talents of each team member

It is very likely that peers within a team will compliment each other on the great achievements they’ve accomplished. The agile coach however, can make note of skills and talents that each individual will have. Being able to reach out to those looking for continuous development, the agile coach can provide mentoring sessions and guidance. The agile coach may also be able to set up agile games that promote deeper learning for the team, as well as agile training courses specific to each role or situation.

4 – Optimizing team performance

When the team has reached its top performance and velocity is steady, the agile coach can look to make sure the dynamics of the teams are protected. By that, it means that despite any change within the teams, the agile coach can identify if there is a good fit for the current team if someone leaves or joins. Also, where there is concern for self-organizing capabilities, the agile coach can explain how everyone can take on challenges and decisions on their own. This can be done by story-telling or giving real examples of how top performing teams have accomplished similar accomplishments.

5 – Keeping a positive outlook in the face of failure

Inevitably with all new developments and innovations that team attains, there is a likelihood of failure and disappointment. In those instances, the agile coach should be able to reach out to the agile working team and explain that it is normal and acceptable. The other important aspect that the coach will do is keep the team’s spirits up despite that. True team building comes with being able to show that everyone can get back up and do better the next time. Regardless of the number of times failure may occur in their agile solutions, the team can learn that it will be able to accomplish a lot more by not complaining or worrying about the past.

As we can see, the adoption of an agile coaching philosophy can facilitate many of the organizational aspects that we take for granted. Some of the points raised above may happen on their own, or may even be forced. Having an agile coach on your side is a choice, but when it comes to company values to keep their teams in top shape, wouldn’t you rather have someone there to give proper encouragement that teams need when looking for guidance?

[Image courtesy of David Castillo Dominici at FreeDigitalPhotos.net]

10 Signs of Unsound Agile Individuals

Posted on by

Top 10 Signs of Unsound Agile IndividualsYou may not always notice at first, but you may come across certain individuals within agile product management circles who although they may consider themselves practicing agile principles, may in fact not be.

Here are a couple of tell-tale signs on how to identify unsound agile individuals, or get some indication that someone isn’t grasping agile as it is meant to be:

1 – They use the term agile to refer to a process

You may see this one as the most common. Where the fact that their development cycles involve the use of sprints, they interpret this as being agile. This is one of the most common reasons why misinformed management see agile as ineffective. Most software development managers and their teams will take certain aspects of agile, mainly in the form of an agile tool, and then try to explain to management that they are doing things in an agile project methodology. Due to the lack of overall understanding of what agile is, this inevitably leads to failure, and the creates the misconception.

2 – They say agile for Kanban/Scrum/XP/Lean Interchangeably

Rather than referring to the synthesis of methods, processes, practices, principles and ideologies of agile solutions, some individuals seem to identify with only one agile practice, i.e. being knowledgeable in Scrum, they speak in terms of Scrum in itself as what it means to be agile. Certainly practicing scrum would be a step in the right direction, but it’s not all there is.

3 – They have a command-and-control approach to management

When someone uses their work title as the only form of authorization and direction to make decisions, you will inevitably see lack of innovation and creativity from the teams they were meant to lead. Micromanaging is counter-intuitive to the servant-leadership approach that agile promotes.

4 – They would rather work alone

You may notice those that like to just do things on their own, and see it at the most effective way to get things done. Agile is not accomplished in a bubble and it requires the full spectrum of agile team roles and the synergy that it provides.

5 – They prefer low-effective forms of communication

If the person you are speaking to prefers regular use of emails, texts, and IMs as their principle forms of communication it will short change the entire chain of communication. The reason for this is that most of those messages lose the original intent they are meant to convey. When we consider that 7% of all communication is words, 55% visual, and 38% vocal, we can see that there are some serious limitations to just communicating in a written form.

6 – They think that agile alone guarantees project success

This comes from many misconceptions, but mainly it principally comes from limited depth in understanding how to become agile. Some people like to throw around agile as a plan for success because they read about it in an article, when in fact they do not realize that using it as a “buzzword” for a solution does not mean there would be the proper steps taken to succeed.

7 – They expect others to “do-as-they-say”, not “do-as-they-do”

This is similar to command and control, but goes beyond structure. We are referring principally to when you have someone who likes to do things contrary to what they’ve recommended or said. Also where they tend to see a sense of impunity, bullying and envy among teammates is along the same lines of where someone has lost the grasp of what it means to be a part of an agile working team.

8 – They do a lot of talking and not enough listening

When you see that someone is regularly the only one talking or interrupting in a conversation, this means they are likely unable or unwilling to be active listeners. This likely could be interpreted to mean that they don’t value your opinion and would rather be in a position of influence rather than compromise or collaboration. This is not to be confused with active participation. If someone is asking relevant questions they are likely listening very closely and want to hear more about what others have to offer in the conversation.

9 – They judge unsparingly

We’ve all heard of tough love, but when you have someone who persistently rants and gives negative, unconstructive criticism it puts a halt on all team synergy. Nobody wants to contribute in an environment where they will be judged.

10 – They have low EI (Emotional Intelligence)

Many people are stuck on having the most knowledge, the most expertise, the most qualifications. All of that means nothing if you do not have a personable way to approach those you interact with. For someone having a low EI means that there’s a lack in ability to distinguish between their own emotions and those of others. This makes communication and trust (among other things), very hard to accomplish. In the presence of someone with low EI, most will interpret that person’s actions as being negligent, narcissistic, arrogant, or unsympathetic.

Giving these examples will hopefully shed some light on the types of signs where others who would likely present themselves as agile mindset individuals. This is not to be used as a means to single out those types of individuals to be banned from such teams, however we do encourage regular agile coaching, training, and courses to help educate them about the impact they take on their overall environment. It is difficult to find people knowledgeable in all areas of agile, as most pick their area of comfort and become highly skilled practitioners in their specific area of expertise.

[Image courtesy of iosphere at FreeDigitalPhotos.net]

Top 5 Ways Agile Mitigates Risk

Posted on by

Top 5 Ways Agile Mitigates RiskIf you’ve ever been on the project from hell, you may be able to relate to the resulting extra costs, lost time, excess waste and lost customer satisfaction. Implementing agile properly can help reduce the occurrence of such shortcomings. The beauty of agile is that it is already tailored to reduce risk and therefore increase the value of the product being developed whether in a manufacturing or software environment.

Parts of an agile framework that promote risk mitigation

1 – Sprint Durations: We all know that the agile framework is founded on sprints and multiple iterations. We can tailor those sprint durations from 2 to 4 weeks once we complete the agile release planning. Is your project likely to be high in risk? Try reducing the duration of your sprint to the lower end of the range. The reason for this is that you are building in more frequent cycles for each of your deliverable features. Further to this, you get to revisit your planning cycle more frequently and determine the accuracy of your agile team velocity in less time, making it more predictable and therefore reducing risk over time.

2 – Retrospectives: At the end of each sprint you are meant to go over all the events and processes that went well and not so well. You then carry these results forward in to your next sprint as your “lessons learned.” Since you will be doing this for each sprint, the frequency of those retrospectives gives everyone on your team the opportunity to tackle ineffective processes, and the chance to implement more effective ones. This reduces your risk of being wide open to possible wasted initiatives.

3 – Backlog Grooming: The ongoing process of backlog grooming for your Product and Sprint backlog allows the possibility of revising and reviewing the priority and importance of the features your team will build into each iteration. This is primarily the Product Owner’s responsibility, but it is supposed to be done in conjunction with the inputs from the rest of the agile team roles and stakeholders. The more frequent the backlog grooming takes place, the more you are able to reduce the risk of ROI loss by not implementing lesser valued features, and implementing immediate returns from your agile solution.

4 – Promoting Transparency: When all stakeholders are engaged in a project, and being at the utmost expression of their intents and expectations, there is less risk for all team members to go off track and building an unwanted set of deliverables. Much of the transparency comes from what is gathered through the accumulation of the events that take place during the sprint such as: Sprint Planning, Standups, Sprint Reviews and Retrospectives. Each of them allows everyone in the agile team to know exactly what is going on and the risk of delivering anything less than what all stakeholders expected is lowered.

5 – Frequent Deliveries and Sprint Reviews: When we get to the end of each sprint it typically represents a similar implementation as one project management life cycle at a smaller scale. The development team is expected to deliver all backlog items that have reached their definition of “done.” Since all backlog items that were completed and demonstrated are added on to the existing product, there is no underlying wondering on how or what the finished product will look like. It is delivered at the end of each sprint, whether as the initial product deliverable or the increment of that initial product with additional features. Since we do this frequently on agile projects, the risk of wasted features is reduced once the product is delivered. Customers get instant gratification since they will get to use the product immediately.

Most risks can be avoided, as much as the agile framework will help prevent them from manifesting. The points to consider then making sure that the risks remain at bay, are to make sure that stakeholders are engaged to the greatest extent possible. It is imperative that the stakeholders involved are genuine and without hidden agendas. This would allow for quick turnaround to address risks and issues presented.

[Image courtesy of jscreationzs at FreeDigitalPhotos.net]

 

How Servant Leadership Increases Agile Team Productivity

Posted on by

Did you ever give a very clean concise explanation to someone who was as asking very general question? You did this with the best of intentions so that you could share your knowledge and hope that the answer to the question was helpful. It probably was, but what you realized then, the only definition of the topic that the person will use at all times was the one you just gave them – without discovering for themselves what the many areas that topic may hold.

It’s not always about what to say, but mainly what not to say

how-servant-leadership-increases-agile-team-productivityAs servant leaders in agile teams, regardless of our the project methodology as waterfall vs agile, we need to identify where there is that fine line between giving finite information vs opening up the level of discovery on that topic by giving just enough to get interests elevated so that your team or individual members will continue to learn about that topic. No doubt, there are many modes of discovery for people in agile team roles. It’s human nature to stop learning when we think that we know all there is to know. Sometimes we feel as though, whatever our leaders or agile business coaches tell us, is all there is to know. This is where there are fine lines that servant leaders might cross. If you appear to be the only source of information in the eyes of your agile working team, you will always be that source and you will not be doing your team members any service. This will prevent your team from becoming self-organized.

Leaving the mindset of absolute control and absolute direction

It is important to realize that there are ways to keep someone on the path to staying innovative and productive. Mainly as servant leaders you need to keep your answers short but provide enough indication that there are multiple relevant sources of information. Certainly this comes with time, you need to somehow be a subject matter expert, or at least have access to some. But the main idea is how to keep the communication clear and give just enough to fuel the need to know more and more, and on a regular basis. The other side to this is to make sure there is no judgement when failure is imminent. We need to see failure as one of the ways we learn. The important part about seeing where the current path is leading to, is not to give too much information where you become the point of reference to each step. It’s easy to follow steps and that is where you may stagnate the innovative mind to just want to follow instead of taking the initiative.

Inspiring has a greater impact than informing

Whether providing agile consulting as agile servant leaders or as agile business coaches, there is greater benefit to being increasingly aware of what some of the side effects of our leadership and communication style may be. It’s fun to give information and know that it’s appreciated. However, if responding usually in the form of a question (i.e. what do you think would resolve this issue? or what issues do you notice come up frequently and why?), you may get your team to think self-sufficiently and get thinking on how to progress with much more impacting results. This will promote the need to attend more agile courses, or better yet create a system of agile games that enables issue resolution. Do not limit the amount of information you can provide, but give just enough and think along lines of quality, not quantity of the information. See it as planting a seed. The growing of the plant grows best on its own while giving it right amounts of soil, sun and water at different times. This is the best way to ensure its growth. It will grow without the expectation that you will need to pull on the stem to expect quicker and faster growth.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

Top 5 Agile Myths and Misconceptions

Posted on by

If you are planning on becoming agile at your workplace, you’ll most definitely come across some colleagues that have a negative outlook about what’s coming. The thing to consider is that everyone wants the benefits of being agile but they are not likely to be committed to actually making the changes to become fully agile. This is where myths and misconceptions come into play to justify potential failure down the road. Keep in mind this failure would not be from implementing agile itself, but rather the lack of actually implementing agile to its fullest potential.

Here are the top myths and misconceptions that must be dispelled or at least brought up in situations leading to disappointing results:

1 – Agile is Chaotic – It certainly isn’t easy, but when implemented properly and with many trained and experienced practitioners, agile can be very organized and structured. There is a lot more planning that goes into agile projects when compared to waterfall. In fact planning is done at the beginning of every sprint, but it doesn’t stop there.

2 – Agile is just a recent trend – Believe it or not agile has been around for many years, and it has taken on many forms over time. The term “Agile” is perhaps more recent in terms of use, but the methodologies that were around previous to what are now encompassed by what we’ve deemed as agile, have been around for many years, and still continue to be used.

3 – Agile needs a lot of training – You need to start somewhere, but experience is valued more than training. Being on an agile project while being open to learning about it, can give you all the training you need. Certainly that comes with asking questions, reading a few books or attending a couple of seminars of agile courses along the way, but there’s no more training than any other process in today’s workplace.

4 – Agile is for small teams – Many people who have worked on large projects might see that agile and sticking only to the basic agile team roles is unattainable, at least in the strictest sense. However, an agile working team can be scaled and works very well with the proper structure put in place. Beyond that, keep in mind agile isn’t purely about the processes it imposes, but also relies heavily on the people and collective emotional intelligence of the agile team adopting it.

5 – Agile doesn’t require testing – For those accustomed to waterfall vs agile projects, most would be expecting to find or look for the QA testing schedule. The one that typically comes at the end of every waterfall structured project. With agile the testing takes place simultaneously throughout the project and is done in a more seamless process, usually facilitated by tools like jira. The testing (inspection) goes on from beginning to end and is part of every sprint.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Sharing is Caring – Why Transparency is Necessary in Agile Teams

Posted on by

In agile consulting there is much emphasis on having all parts of the agile team working together in the same direction, that even when there is conflict, it is mainly constructive. With that we tend to give rise to quick failure only to give a quicker solution so that progress continues. When all parts don’t communicate and hold back, the system falls apart. An agile working team is based on the principle of being transparent – no secrets!

The Agile Team Dynamics Working Toward Transparency

When we think of the primary agile team roles (Scrum master, Product Owner, and Team), we might be easily swayed to think that they are a distinct and separate part of the whole. In some ways yes that is true, but in every other way, they are a very synchronous part of the agile system. That is to say, they always communicate much in the same way that the human brain works with the other parts of the 5 human senses. When one part hears a sound, the entire brain works together to analyse the situation so that when there is a sense of danger or harmony, the reaction is acted upon without judgement and without resistance. All parts work together to give a common result.

sharing-is-caring-transparency-in-agile-teamsThe other benefit of all senses working together in one’s brain, is that new and more intuitive senses come into creation. When you see that everyone thinks about something right before someone else is about to say the same thing, you know that there’s much more at work than the regular senses can provide.

What Breaks Transparency

If there is one thing that breaks all forms of constructive progress is fear. Much like Roosevelt’s saying “Only Thing We Have to Fear Is Fear Itself’,” that is a very true statement. Much like every other team, there are causes to what might keep others from sharing and communicating information effectively, and therefore reducing transparency.

Here are a few of such causes of fear:

1 – Failure – Someone can have a great idea, but as a result of fear of failure will hold back from sharing with the rest of the team. Think of all the ideas we had that we thought were ridiculous, but when someone else acted upon it, we found out it was a great and highly popular or profitable invention.

2 – Lack of Trust – When we get over the fear of failure we may traverse another realm of fear, the lack of trust. We might actually get to the point where there is self-confidence in what we might be able to contribute to the team, but only to be taken down by the possibility that someone might steal your idea or even worse, take all credit for it.

3 – Past Experience – This is a big one. Due to societal anxieties and situations that cause many to try to avoid the past, many try to undo or avoid what may have happened in the past. What most might not realize is that every team is different, even more so, is that there are many more situations out there that might seem the same as previous one, but are in fact not the same due to even slightly different variables.

4 – Success – You might ask, how can this be??? Well many people think that success is going to change their life so in many ways this is the fear of the unknown. What this might mean to a further extent is that many are afraid of the attention gained by success because they don’t know how they will react to it.

How do we get past fears?

Agile processes and methodologies strive for bringing out intuition to the team members and groups that adopt them. With that comes about the need for many angles toward increased knowledge and practice. The ways in which to accomplish agile solutions, and perhaps break the habit of fearful thinking is by attending online agile courses, agile training sessions, agile games, agile consulting, or better yet just get an agile coach on your team.

A business coach would be able to analyse and review an agile project methodology, and pick out what areas of fear that could be holding a team down. Getting to the bottom of what is preventing the team to move forward will get team members to gain speed and velocity much more quickly and build on team synergy that is remarkable if set in the right direction with the right ideas.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

How to Prioritize Backlogs with Agile Teams

Posted on by

When we look at a long list of tasks to complete, we sometimes lose focus on deciding which ones really matter with regard to any specific criteria that would give us the intended outcome. The simple answer is to say that everything on the list is urgent and important, but it isn’t always true. Sometimes level of importance changes with time and it is for that reason (or at least one them), that we have separate backlogs for each sprint in an Agile project. There’s a list of tools that we can use in Agile that would allow us to sort it out, however we need to change our mindset first before we go there.

How do we know what needs to get done first?

When we look at all features we would like to build into our product, we tend to get an indefinite sense of their importance. Common thinking will naturally lead everyone to say that everything in that backlog will need to be done. It may be true, but as we know there are factors to consider before giving all items in a list a high priority. The other issue is that most of us think we know what we want, but then are influenced by factors that are not necessarily our own. From a business stance, we may be acting on behalf of another group of stakeholders, so outside influence might be a consideration to some extent. In certain cases, where there is very little known about a product we are about to develop, an event called an Agile Spike used to elaborate and analyze the feasibility of a suggested product.

Can We Determine the Difference Between Urgent and Important?

prioritize-backlogs-agile-teamsThe first, but often skipped step in prioritizing agile solutions, is to create backlogs with an order based on a fixed set of criteria. Even then, we tend to group items that are urgent and important into the same batch. If we look at the list during agile planning and think in terms of reducing risk, we may be able to get a clearer idea of which items we need to address first. Also keep in mind that risk and value have an inverse relationship, wherein if we reduce risk, we are also increasing value. To think of this in other terms, if we had a usable product that was absolutely risk-free after purchase, we would certainly value it more than it’s risk-prone alternatives.

The second way to look at prioritizing our feature list of items is by looking at potential return on investment (ROI) especially as part of agile release planning. When we get a feature that resolves the majority of risk, but also gives us a monetary return, it should be included as part of a strategic agile product management plan that increases potential for profitability and long-term sustainability. Hence by prioritizing we give ourselves the benefit of continued growth to the business.

Lastly, we can look at what to prioritize from the current market outlook. This would either be in regard to latest or upcoming technologies, purchasing trends, expert insight, demographics, etc. If we anticipate that there are certain events that will take place in the near future, we can give priority to our backlog items.

Recommended Tools:

MoSCoW method, High-Medium-Low, 1-2-3-4-5, Priority-Impact Matrix, Action-Priority Matrix, NPV.

How do we narrow it down?

As always, agile processes are constantly evolving and this is where regular agile courses and agile consulting can add value to your entire organization. There are numerous ways we can prioritize a backlog and structure the thought process. The main point to consider is that we should not base it on a random set of criteria, but rather a more decisive one in which an agile working team can have a fixed set that is used throughout prioritization activities. Your criteria should resonate with overall business goals and targets. The key is to avoid making it overly tedious try to establish the activity as an agile games session (i.e. planning poker), and establish a set of 3 to 4 criteria that everyone agrees on that would facilitate prioritization and make your efforts worthwhile.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]