communication

The 5 Why’s Approach – Building a Culture of Learning

Posted on by

the-5-whys-approach-building-a-culture-of-learningIs an initiative failing? We knew it! Was a mistake made? By who? If a mistake happens, we typically look for someone to blame. In turn, many of us will avoid risks or will play it safe to avoid being pointed out. Progress suffers from fear of taking action. Making this even worse, the finger-pointing kills curiosity and with it the chance to learn. What can we do to prevent this?

If We Want Progress, Mistakes Must Happen

Mistakes happen. And if today we preach risk-taking, speed and experimentation, we have to expect even more mistakes. Giving people more responsibility while enabling autonomy, means giving more opportunities to fail.

A person who never made a mistake never tried something new.

The number of failures is an indicator of risk-taking along with initiatives to explore new and better ways of doing things.

Some companies aim for a defined number of mistakes/failures to encourage employees to try more “new” things and to think in even wider and various directions. A nice example is the Google Graveyard, which lists projects “Killed by Google”. A sign of Google’s exploratory ambition.

Looking at the average organization, the risk (in cost, credibility and reputation in the market, etc) is often too high to encourage a high number of attempts with very low probability of success. However a “failure friendly culture” is also about simply being bolder in ideas and execution, about the courage to experiment. It’s about being able to react more quickly to changes in customer needs, technology or the market by taking risks and relying on trial and error. Their focus is on promoting an adaptive organization, a learning organization. Thus, it is above all about appreciating mistakes as opportunities to learn.

Learning from a mistake or failure begins with reflection. Many objective but also subjective (non-judgmental) impressions must be obtained and analyzed from different perspectives. Where was the cause? Can a pattern be identified (in the case of several such events)? How can we eliminate or neutralize the cause in the future? What can we learn about ourselves and our work that will help us do better in the future?

Blame Causes Defensiveness and Blocks Reflection

If we are too busy trying to find someone to blame, we don’t really ask ourselves the above questions in the first place. And the one who could have given important input to the questions – is too busy defending themselves. Or worse yet, that person might be influenced by the company culture and is getting ready to point fingers at someone else. In many companies, a culture of blaming is the result of a tradition of punishing mistakes. People lose their jobs or reputation (or both), and experience minor negative consequences.

In order to prevent a culture of blame, there also needs to be an atmosphere of openness, psychological safety, to be able to reflect and learn. Finally, practice is needed here. Helpful techniques can also rekindle curiosity and exploratory ambition in the workforce.

A number of techniques can also be found in the case of, but not limited to agile methodology. Let’s look at this one, the “5 Why’s” – Five sequential why questions (aka Root Cause Analysis), illustrated by the much-told example of the Lincoln Museum.

The 5 Why’s Example

“The National Park Service was faced with a problem that the exterior of the monument was deteriorating rapidly. To address the wear and tear, the stone would require periodic costly replacement or restoration. Via the 5 why questions posed by Park Service leaders to the maintenance crew, the problem was more easily resolved.

1- Why is the material deteriorating so quickly?

Answer: Because of the high-powered sprayers used to clean the monument every two weeks.

2- Why are high-powered washes required every two weeks?

Answer: Because of the amount of bird droppings on the stone.

3- Why is there so much bird droppings?

Answer: Because many birds come to feed on the spiders.

4- Why are there so many spiders?

Answer: They are attracted by the many insects that are all around there at night.

5- Why are there so many insects?

Answer: They are attracted by the powerful spotlights used to illuminate the monument at night for tourists.

Instead of turning the lights on two hours before sunset, they were turned on 30 minutes after sunset and turned off thirty minutes before sunrise in the morning. The number of insects was reduced by 90 percent – problem solved.”

This example points out that the focus should be less on jumping to conclusions and giving out guilty verdicts, and more on better understanding (and then influencing) the circumstances that lead to the mistake.

Treat Mistakes As a Cognitive Challenge – Be Curious!

Curiosity – how did the failure occur? Why did an idea fail? Analyzing the circumstances together to find the weak points. Accept failure in the past as a cognitive challenge to become smarter and better. Over time, the lack of placing blame and shame on people will support a learning orientation in the organization – a common eagerness to draw the most helpful insights from the event and to derive from this the best measures for the future.

Read more about dealing with failure and creating organizational agility on a behavioral level in the book “The Agile Culture Code – a guide to organizational agility ” (Puckett, 2020).

Contributing Author

Dr. Stefanie Puckett has lived and worked globally for several consulting firms, in management and global roles for a Fortune 500 company and ran her own business. She is a psychologist that turned to agile once she saw that decades of organizational psychology research are basically summed up in the agile manifesto. Since then, agile transformation has become her passion as a consultant and executive coach. Stefanie is author of “The agile culture code – a guide to organizational agility” (BusinessVillage, 2020) and co-author of “Agile Leadership – leadership competencies for the agile transformation” (BusinessVillage, 2020).

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Delayed Gratification for Better Self-Control

Posted on by

What is the most ideal trait for success?

delayed-gratification-better-self-controlThink of the trait that you would most likely want to have for personal success?

Many people would guess intelligence as a definite and safe answer to that question. But in fact, many have ignored the trait that they absolutely need to develop to be able to relate best to people in society. Think of how many problems people seem to report on a daily basis, even those that seem to be successful or wealthy. What is necessary to take into consideration is their success in relationships as the main factor in their overall success. Some people never ever seem to have any problems, while others always seem to have problems lurking in all corners and areas of their life.

There is no magic solution to resolving issues in life, but the ability to delay gratification and having a high level of self-control, appears to be a major trait that could solve most social issues, and it could very well be an important one for all people to develop for all aspects of their social life either personal and/or work-life.

One must keep in mind that better self-control is to actually reduce impulse reactions and outcomes. However, one might think that someone with intelligence may have better chances to have increased self-control, this is a misconception and is not as much a predictor for various indicators of success.

The Case for Self-Gratification and Results

Bing Nursery School did a simple study based on Marshmallows with children of 4 to 5 years old. They were presented with marshmallows and were told that if they held on to 1 marshmallow for 15 minutes, they could get a second one (doubling their first). So if they ate the first one, they wouldn’t get a second one. All the while, the kids were also being filmed since they were told that they would be left alone to decide and during those 15 minutes. Some children couldn’t hold back, but others did, and convinced themselves whichever way possible that they should not eat that first marshmallow. An example of that study can be seen here: Marshmallow Experiment

The initial results of that study were not the only relevant ones, but in fact, what came later on in the lives of those children. It was shown that the children who held off eating that first marshmallow therefore having the ability to delay their gratification at that time, later in life went on to become a lot more successful, wealthier, as well as more physically and mentally healthier than their counterparts who couldn’t hold back. Further to that, these same children who delayed gratification, also had better quality relationships, specifically less breakups, fights, and divorces.

Further studies on these children as adults, have shown that the adults’ brains not only functioned differently but were also structured differently. Specifically, the section of the brain concerned are the frontal lobes, and those with better self-control (less impulsive) had smaller lobes. This was a result of less impulse activity since the size of a brain’s frontal lobes are known to be correlated to the level of impulse.

Practice Builds Tolerance and Self-Control

How do we apply this to our own lives and to our agile practice? There are ways to develop your self-control and delayed gratification. Just like any physical exercise, the key is to do it gradually and consistently over time.

The most common practice to develop this is by first creating a list of goals that you may have. These goals may be related to personal life or workplace. Be aware that this delayed gratification activity may somewhat be energy draining at first if you are not used to having a high level of self-control, but it will indeed make you better at it. The idea is to pick something that you would frequently do in the day, and once identified, make sure to do it less and less in the day. This does not necessarily have to be a bad habit, but would certainly be a good start.

Examples would include:

  • holding back from those extra sugary snacks or drinks in the day,
  • delaying that next urge to smoke a cigarette or vape,
  • sticking to that one task from beginning to finish without being distracted about the other remaining tasks that you might feel need to be taken care of in the same day,
  • holding back from reacting toward a fellow co-worker regarding a simple error or mistake
  • taking a walk to your local destination instead of driving there
  • cooking your food instead of ordering take out or microwave meals

Observe your list at the beginning and then at the end of the day, and do this day-by-day for at least a week to see whether or not your results improved or not. For those who practice agility this can easily be setup as weekly sprints. The key to understanding this, is to observe your level of motivation or level of energy from delaying your gratification. You may even notice that your goal results were achieved a lot faster and higher quality than you would have if you didn’t delay gratification. One must realize that self-control also has a threshold in capacity, therefore, the more you can practice delayed gratification and self-control for one thing, it can promote better self-control management efficiencies for others. So if you do not practice self-control, do not be surprised that you find yourself slipping out of control most of the time because you have no time to focus on any particular one.

Image courtesy of ddpavumba at FreeDigitalPhotos.net

The Dangers of MVP with High Product Expectations (HPE)

Posted on by

dangers of mvp with high product expectationsIn the context of Lean principles the Minimum Viable Product is known in practice as the MVP. For most, the use of that term is used liberally and sometimes even dangerously when used to represent a finished product. The problem arises when there are expectations well beyond actual possibilities at the time of signing, planning or initial sprint. Of course with reason, nobody knows what to expect until the product is completed.

Defining HPE

We are using the concept HPE as an acronym to represent High Product Expectation. In this context, High Product Expectation is what the client expects as the finished product right from the start, with the additional possibility of more features. As you could guess, the MVP should never be equal to the HPE. By this we mean that you should never expect the completed product as an MVP to have a full set of features and attributes.

MVP Expectation Pitfalls

The above sounds like common sense, but many projects from time and time again, are built with ridiculous expectations at the signing of a contract or initial product specifications, they become sealed with the expectation that a minimum viable product (MVP) will be built, even with the utmost transparency. This is not a problem in and of itself, but this step is seldom dived into or taken seriously during the different stages of a project from beginning to end. We tend to skip through the process, whether through ignorance or negligence, and as a result take for granted that should we actually “do things properly” so all will turn out well. This could also be from a lack of negotiation, rush to get started, because after all, everyone acts like there could be a ticking time-bomb that could go off at any time. Certainly, time of is of the essence, and nobody wants to lose out on the opportunity cost. But the loses incurred down the road would be best prevented at the very beginning.

The Lessons Learned and Questions Asked

In the end we could all be optimistic, and rely on good faith, but most projects start with best intentions, and how they end is a different story. Actually, the only real moment the customer starts to ask ‘serious’ questions about what was expected to be built, ends up being at the end of the project, or at signoff. Not to confuse, “definition of done” with actual “completed product,” but these terms may eventually be intertwined as well, and could be used at times of disagreement, leading to a never-ending cycle of argument, discouragement, disbelief, loss of trust, loss of morale, and just plain waste of time. The client may have had another understanding of what the MVP was. It is very likely they thought it just meant the “first version” of the product. That is where things can go seriously wrong.

Certainly if agile principles and methodology are being practiced properly, there shouldn’t be any surprises when the end of a project comes. We all know too well, that expectations or better yet “defining expectations” has no bounds. When it comes to meeting expectations, there’s a lot of politics, assumptions, and a lot of finger pointing as to who expected what and for what dollar amount, especially when there are hidden agendas.

So when we talk about MVP, we need to ask the client important questions like:

“What are you willing to accept?”
“What are you really looking for?”
“What are the features you’d be willing to let go of if there we run out of time or budget?”
“Who’s expert opinion is being questioned?”
“How much time do we have to learn about what the market wants?”

Preferably these are questions that you should ask at the very beginning, but definitely consider re-asking those questions and bring out those assumptions throughout the project, from sprint to sprint. The Product Owner or Business Analyst should be keeping tabs on these questions, but relevant questions should always be asked over and over again, with emphasis to determine those expectations. Keeping track of those answers is also key to making sure those expectations are met. You may eventually notice that the answers change as each sprint, stage, or phase is completed. With those changes you can eventually challenge why there have been changes and assumptions, in the hopes of getting those answers and dig deeper to find out who’s behind them, perhaps gaining some extra transparency. Don’t be afraid to ask who’s expectations (or assumptions) created those changes to the original ones. You may be surprised to find out it’s not the same stakeholders who are behind the original ones; more people may have gotten involved, or maybe switched in or out of the project.

With these basics covered, you should be able to gain higher levels of understanding on what the client was expecting. But to further this understanding, you should be able to gauge whether or not the client was setting them too high to begin with. Put differently, if the client had high expectations (HPE) at the beginning of the project (i.e. little or no knowledge of what they were going to get from the MVP) it would be unlikely for the client to lower their expectations by the end of the project. If expectations were described as a type of force, this explanation would represent a metaphoric ‘inertia’ that tends to increase in a project over time, once in motion it does not diminish.

[Image courtesy of jscreationzs at FreeDigitalPhotos.net]

5 Inefficient Communication Habits That Cause Waste

Posted on by

5-inefficient-communication-habits-that-cause-wasteIt’s not hard to believe, we have a tendency to waste a lot of time communicating whether it be through face-to-face, talking, texting, emailing, or chatting online. The problem with that is that everyone’s bad habits can get the best of you whether you like it or not. Have you ever gotten that email where you can’t decipher whether it was a request? some sort of prank? or yet something absolutely serious?

We all know the situation could be better, as many do in today’s day-to-day lifestyles, people claim they no longer have time for the simpler things in life, just relaxing or taking the time to do something truly for themselves. Below we’ve identified some of the bad habits that you may want to avoid, and for your own sake, be able to identify from other before you get pulled unnecessarily into someone else’s trap:

1. Putting “Quick Question” in the Email Subject Heading

The intent of someone who puts “Quick Question” in the subject heading of an email is certainly obvious: they have a need to resolve a question quickly. The problem is that the intent is a setup for one’s own need to get immediate gratification at the receiver’s expense. The question you have to ask yourself is how “quick” does a question need to be answered, and is it worth stopping what you are currently doing only to be distracted by someone else’s supposed “quick” needs. You may need to consider that there are times when someone’s need for a quick answer is valid i.e. a life-or-death emergency situation, but if you are seeing this type of email regularly coming from the same person, it indicates that they are certainly not taking their own time to get a little more organized. Then ask yourself this: Would you distract yourself from someone’s “quick” question, if they can’t get themselves organized? We are tempted to say “yes” if it was a situation where it was our customer, after all they are paying for it. Or are they? In the grand scheme of things you are doing both yourself and the customer a disservice. First, they will never learn how to organize themselves with prioritized efficiency, and second it will always be to your (and your company’s) demise as you keep your phone or emails rolling in for around-the-clock response times that weren’t necessarily part of the contract.

2. Calling With No Advance Warning About A Complex Question [something you couldn’t possibly have a quick answer to anyway]

We all know, receiving a call from someone in need is something urgent, should be taken seriously. However, you should be cautious about the intent of those who call others about a complex question that needs to be answered on the spot. The quick answer to that is “Can I call you back with the answer?” If they don’t want to give you the time to research and respond, then you know you may be facing issues about your response later on. The other way to prevent any misunderstandings is to ask that they send you a followup email outlining all issues in the question that needs to be addressed. Note, we are referring to a “complex” question. Failure to get this outlined in writing could present some issues down the road, as you run the risk of having to address “unmentioned” questions that they “thought” they asked you during the call.

3. Requesting Something That Could Easily Be Answered From An Online Search

Unfortunately, we all get this a little too often. In the age of Google, we still tend to get even those seemingly difficult (and more often simple) questions that can be easily answered by just looking it up online. As you may have guessed so far, we are referring mainly to the question “Can I answer this on my own?” Forcing someone (whether directly or indirectly) to answer a question that can so easily be answered is not only going to frustrate them, it could potentially cause you to not be taken seriously by peers. It could potentially create the “boy who cried wolf” scenario.

4. Sending Really Long Emails

Sometimes it’s necessary, but beware of the really long email. Unless you are sending out a newsletter or occasional email with reference to updates within your department, a really long email is what can cause many to just ignore right there and then, and for the next time around. We often forget that an email was meant to send a message, not a book… On this topic we are mainly concerned about quality not quantity. Many write their emails while restating the same issue many different ways throughout the body of the message. This only frustrates the reader while forcing them to read to get to the bottom of it, then only to notice they wasted more time reading it than it was worth. If you can’t get your message across in fewer words, then others may not see the point in reading your email. A good way to avoid this is re-read your message before sending it. If you find that you get bored or confused by your own email, consider that many others will certainly feel the same.

5. Sending Text Messages Even Though They Don’t Get An Immediate Response

The texting phenomena is at full stream. We all seem to do it, sometimes while driving, walking, or talking (if you do then STOP!!!). Let’s admit it, we all feel like it’s ok to text no matter what other activity is going on around us. The problem is that we don’t realize that we are creating a norm that we feel is ok, while many others (the silent majority), feel is inappropriate to do. Among these, is sending multiple consecutive messages to your peers while they may not be able to respond immediately, or better yet, they may not even see them by the end of the day. The last thing you want is having someone catching up with a backlog of messages, as the sender is rambling about something that couldn’t wait for input from the receiver in the first place. If that tends to be the case, a phone call may be a reasonably better alternative.

While the topics in the list above may seem obvious, there are many who don’t realize the auto-pilot mode that technology has all put us in. That is not to say that technology is bad. But what it does say is that we need to take it a lot more seriously, and more importantly we need to consider how we are affecting others in the process. If you are not taking your own habits (and time) seriously, you can’t expect others to do the same.

[Image courtesy of marcolm at FreeDigitalPhotos.net]

Major Hurdles to Agile Adoption in Government Organizations

Posted on by

major-hurdles-agile-adoption-government-organizationsDespite what you’ve heard on the news about the federal debt, many federal, state, and local government agency budgets have been flat or declining for several years. Add in inflation and other cost increases, and these agencies are constantly being asked to do more with less. For the IT departments, this surely means they’ve made the transition to lean, mean, Agile teams, right? Well, no. But there are some good reasons for that.

Responsible Spending and Risk-Aversion

Government organizations usually have budgets that are determined by politicians and other actors outside the agency itself. Unlike companies that can expand budgets through increased revenue and profitability, government agencies need to justify budget requests by showing they have a responsible track record deploying their budget to meet their mission.

Tax payers don’t want the government making reckless decisions with their money. As a result, government organizations routinely make decisions that can be justified as responsible, risk-averse, or “safe” – even if those decisions are not the most efficient or cost-effective. I’ve heard it said that nobody has ever fired a government employee for using Microsoft Project on an IT initiative. In an environment like that,  a half-century old methodology like Waterfall – or a century old tool like Gantt charts – would be seen as preferable to newer methodologies that are not well understood to business or political stakeholders.

Delivery Dates vs. Sprint Cycles

Government IT solutions and systems are often the result of new laws or regulations, and have a defined time period in which they must be implemented after the new law is passed. Just like the adage, “requirements may be vague, but the software will be specific,” laws may be vague, but the regulations must be specific, and the software that implements them must be even more specific. Elements like complex business logic and multiple system interfaces cause managers and business stakeholders to ask for lots of documentation to prove that the system was built correctly.

When a new law mandates implementation by a specific date it creates an anchoring effect, that the system needs to be “done” by that date. Briefing senior government officials or even legislators on sprint velocity and burn rates is a much bigger challenge than providing dates and percentages. Even if, in the end, delivering the most valuable 80% of a solution on time should be preferable to delivering 100% of a system after a 1-2 year delay.

Software and Tools

Another reason no one in government ever got in trouble for managing an IT project with Microsoft Project is because it is already on the list of pre-approved software for use that nearly every agency maintains, in one form or another. Hardware and infrastructure requirements are a common consideration, as are licensing costs. But security concerns are an increasingly big reason why software on pre-approved lists keeps getting used instead of newer or better products being adopted.

Getting software tools approved for use at a federal agency means completing a thick stack of paperwork. It also requires a champion to spearhead the process, work with Help Desks on administration and conducting training. This means longer-term commitments to tools than in the private sector, and that larger companies with established products get used more often.

End User vs. Customer

Until recently, most end users of government IT systems were employees of that agency, so there was little conflict in seeing the end-user as an internal customer. As the internet has proliferated, more businesses and individuals are interacting directly with government IT systems: submitting applications and appeals, self-registering or updating information, or just searching for general information on a government website or portal. These external end users, or government customers, present a unique tension when designing systems for them.

While “the customer is always right” is a great motto for many private businesses, government agencies need to walk a fine line with that approach. They run the risk being too accommodating or “too cozy” with the people and businesses they regulate, and can erode trust that the government agency can regulate or monitor effectively.

Tight budgets, pre-defined timelines, and the need for some agencies to keep end users at arm’s length make it easy to de-emphasize agile principles like personas, end user demos, and usability sessions.

Contributing Author

David Pradko is a project manager and certified business analyst, who has worked with over a dozen government agencies to design and implement IT solutions. He as also appeared at the IIBADC’s Business Analysis Development Day and on Federal Tech Talk radio to discuss Agile in the federal government.

You can follow David on Twitter at @DPradko

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

Automation is Key to Agile Implementation

Posted on by

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

Agile Ceremonies and built-in automation

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

Keeping it Simple

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

Consistent and Regular Adaptation

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

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

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of Idea go at FreeDigitalPhotos.net]

6 Main Reasons Why You Must Identify Backlog Item Dependencies

Posted on by

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

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

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

1. Reduced Overall Project Risk

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

2. Value-added Efficiencies in Process Workflow

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

3. Facilitation of Priorities

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

4. Early Elimination of Blockers and Time Wasted

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

5. Proactive Conflict Resolution within Teams

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

6. Increased Morale within Teams

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

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

[Image courtesy of tigger11th at FreeDigitalPhotos.net]

 

Agile Culture: Stop Wasting Time On What Can’t Be Resolved

Posted on by

When attempting to make great accomplishments, we tend to look at issues in the workplace, or in everyday life as opportunities to be resolved. This may distract from solutions that are very obvious and perhaps more urgent or easy to resolve. You may have heard of the expression “low hanging fruit.” Typically you would hear this when tackling a new opportunity, or when there’s a clear advantage to achieving a milestone or accomplishment.

Where is Your Company Placing Importance in Their Culture?

Keeping your sights on what the top priorities are, will likely keep things lean and mean. But outside the obvious, we are also referring to what is not obvious. Circular discussions in meetings, persistent and unattainable targets that never get met, can definitely be a drain on time, resources and motivation. Some companies tend to place importance on resolving issues that can’t be resolved as the next step to a break-through. This could be fine if there’s nothing else to do, but as we may all realize, time and resources are usually restricted. In a few words, why concentrate on what you can’t do, when you can concentrate on what you can do? So much time gets wasted on the “can’t do” mentality, when it’s just a matter of approach that needs a switch or refinement. Yes, this may seem a little philosophical at the moment, but being agile does really place importance on what is being done and how to adapt new ideas and processes to what was previously done.

When a team gets stuck in anti-patterns like analysis paralysis, a stagnant state that is usually caused by concentrating on what can’t be done at the moment, is a direct result to over-analyzing beyond the knowledge, developments, or tools available today. So if your team collectively doesn’t have the knowledge or tools, the low hanging fruit may just be to concentrate on obtaining the very knowledge or tools that will get you to the next step.

Getting out of Anti-Pattern cycles

A common cause of what may create a stagnant environment is the thought that all members of a team have all the knowledge needed to resolve an issue. But again, this is more of a pretentious approach whereby everyone avoids the realization that some learning is required. The problem is, nobody tends to want to step up and be the one to say that they don’t know. This kind of attitude is usually shunned upon and seen as weakness in many companies. But what does it really mean to be “weak?” Is it admitting that you need to do some learning and getting right to learning? Or admitting that you know it all and that you can waste everyone’s time pretending that it can be done?

Learning is Not a Weakness

Ultimately, what we can observe in the situation above, is that company culture can affect the decisions and approaches that employees will take. It’s not about always taking the safe route, but allowing for mistakes to be made, and also not to perceive those who admit to needing more to learn as being the weak ones in the room. In fact, this is probably the reverse, those that need the most learning and admit to it, will actually be your strongest employees. These are your true pioneers, as they have the approach needed to admit failure in times when it’s necessary to take a bold new step to a break-through process, or discovery. The company culture will guide that behavior, so it is best to re-evaluate and adjust accordingly.

[Image courtesy of stockimages at FreeDigitalPhotos.net]

Joining an Agile Team? Know Your Personality Type

Posted on by

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

Why are Personality Type Considerations Important?

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

What Types of Personalities are There?

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

Knowing Personalities: A First Step Toward Leadership

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

5 Important Agile Interview Questions

Posted on by

5-important-agile-interview-questionsIf you are looking to recruit someone new in your company whether it’s for a new Agile implementation, or to replace someone who left, it’s important to get specific Agile interview questions asked up front during the recruitment and selection process.

Below we’ve outlined some basic yet relevant questions that you can ask a potential candidate, and gauge whether or not they are going to be a good fit for your department, team, or organization. That is not to say that your candidate should answer all of them correctly to be considered the perfect member to add to your team, but they should be within some level of understanding on why these questions are being asked.

1 – What does Agile mean to you?

For this question,  you should be looking for closely related Agile principles and values. It’s important to see how close your candidate can get to mentioning and explaining those values of:

A. Check whether your candidate is referring to how they like to interact in groups, looking to share ideas and solutions while promoting team building and servant leadership. If they tend to emphasize the processes and tools, this might not be such a bad thing but you should try to steer them into more group dynamic and group transparency based topics. If they don’t respond or get sidetracked to following orders and making sure everyone in their surrounding work environment must conform to process, this might be a less suitable candidate. However this is not the only basis on which to make your decision.

B. Many who try to impress in an interview, tend to throw ideas out of which documentation they would create and use throughout an agile project. It’s important to see if your candidate sees the value of delivering a working product. If they are the type of person that is trying to make sure everything works around the product except for the actual delivery of the product as necessary, it’s important to see if they are making this distinction.

C. If your candidate is more concerned about how many contracts they can get out of the customer, they might not understand the importance of the other aspect of Agile values which is to try to gain as much customer collaboration as possible. You wouldn’t want interactions with the client to be about how to draft a new contract every step of the way. Remember it’s the soft stuff (people skills) that’s the hard stuff, so your candidate should be able to demonstrate how they are able to engage the customer into problem solving discussions and come to mutually beneficial agreements.

D. If your candidate seems to be more concerned about project plans and gantt charts, they may be stuck in a waterfall mindset. These plans in an Agile setting are a distraction to actually executing the process of developing actual product. For this you should be trying to see if your candidate is looking solely to write-up a plan and make sure everyone follows it (command-and-control) vs. being able to point out the inherent importance of having a team self-manage and create a product based on prioritized features that a market is ruling as important for ROI.

2 – What types of Agile processes have you implemented before?

With this question, you should be able to get the candidate to point out if they’ve actually implemented Agile methodologies whether they are Scrum, XP, Lean, etc.. Key words that you can look for are those found from the beginning to end of the cycles. Words like Sprint Planning, Kanban Board, Burndown Charts, Retrospectives, etc.. You should be able to check and see whether they have an understanding of the ceremonies and events that occur through iterative cycles. More importantly, they should be able to point out why those processes exist and how they fit together to make a fully Agile environment possible.

3 – What is your idea of an Agile mindset?

The character and personality of your candidate fundamentally must be a good match to the agile mindset if they are to practice Agile. Common sense, right? however you might come across some who think they know what it means to be Agile but portray a completely different mindset. You may want to have a look at our other related articles that shed some light on what qualities an Agile Mindset has (or does not):

4 – How often must Agile be practiced during a project?

The answer to this one is simple: at ALL times! If your candidate starts to mention which aspects of agile should or shouldn’t be implemented, as if to compare switching it on or off like a light switch, this person may not actually understand the importance of synergies built over time through agile principles. This question is best answered in a holistic overall “outside the box” sense. Agility is not to be pulled apart and peeled only for certain parts and principles. This leads us to our next question.

5 – Can Agile be tailored?

This is a very important question as the candidate should be able to read between the lines. In practice it’s well-known that you should not be tailoring Agile right from the start unless you have many years of Agile experience. Many of the reasons why Agile fails, is because it is tailored to fit another mold, i.e. trying to fit Agile into Waterfall, and this is where false beliefs about the effectiveness of agile come in to play. Your candidate should be able to respond with a “yes, but…” type of answer. From there they should be able to point out that tailoring is not ideal, and that it would take place perhaps after multiple iterations and sprints, where the agile team notices certain events or processes that aren’t working well for them. This would usually be coming from the Sprint Retrospectives and observed in each successive retrospective to see whether they’re continuously improving or not. This makes the tailoring process more safe and tuned to the team’s needs.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

 

5 Healthy Workplace Habits by Using The Scrum Process Model

Posted on by

5-healthy-workplace-habits-by-using-the-scrum-process-modelThere are many ways to do work, and to be honest, not many people are taught how to create good or optimal workplace habits. That being the case, workplace dynamics can range from being a cesspool of toxic behavior and habits, to one that has an environment of the utmost respect for one another. The environment created in most workplaces is a cumulative result of individual behaviors happening at a given time, much like society, but only much more concentrated since we’re left to interact daily from morning until afternoon with our work colleagues.

The following factors, as part of the scrum process model, are found to reduce stress, anxiety and in turn increase workplace  motivation and productivity:

1- Intermediate Deadlines (The Sprint)

It has been shown that when work has no confinements and there is “no light at the end of the tunnel,” the level motivation steadily declines over time. Further to this, the likelihood of burnout and employee turnaround starts to become more and more apparent. The Sprint as a 2 to 4 week timebox that is meant to happen iteratively, gives a mini-project sense to accomplishing each round that expectedly gives a delivery of product. Intermediate deadlines in this case, tend to occur frequently and regularly give a sense of accomplishment and cyclical motivation.

2- Sense of Purpose (Sprint Planning, Sprint Goal)

When Sprint Planning takes place, there’s a chance for everyone on the team to set their sights on how much work can be estimated for the upcoming sprint timebox. As part of the Sprint Planning activity, a Sprint Goal is set by the Product Owner that enables all involved, the focus and vision as to what they will all being working toward by the end of the Sprint. Consequently if there is proper buy-in at the start with all sights on the sprint goal, it will give that sense of purpose that everyone can focus on and relate to for achievement.

3- Doing Things Better Every Time (Sprint Retrospective)

As most workplaces allow their employees to become complacent, and resulting in lack of performance feedback, the Sprint Retrospective allows for that time where everyone as a group can look at what were the great and no-so-great behaviors of the previous sprint. This sets the course for getting better on an iterative basis as this is done in each sprint. What some people don’t realize is the advantage of thinking of what to “stop doing” and what to “start doing” is already a two-fold way of taking on good habits. This is a bi-directional thought process, since most people typically think of improvement in one direction such as “just do things better” and leave out “what bad habits should I leave out of my routine.”

4- Great Support Network (Daily Scrum/Standup)

Everyone knows that an ongoing support network is a great positive factor. The daily scrum/standup allows for everyone to confirm what they were working on the previous day, and what they will accomplish for the remainder of the current day. The key part of team support for that day is when impediments and blockers are reported. This is a chance for everyone to chip in and see if there’s a way to resolve the blocker. This isn’t just the job for the Scrum Master, but also for the rest of the team. So the blocker announcement starts at the scrum meeting, but gets resolved outside of the meeting with the relevant members of the team, most likely those that are knowledgeable in the area of the impediment. Everyone else continues on their existing tasks to make sure productivity is not impeded.

5- Being Able to See Results  (Daily Scrum/Standup, Sprint Review, Sprint Retrospective, Sprint/Kanban Board)

The structure from which we have a sprint allows everyone to see results on a regular basis. Whether it’s on a daily basis (Scrum/Standup) or by sprint duration (Sprint Review, Sprint Retrospective). We are able to see and experience results on a very constant basis. Along with tools such as the sprint/kanban board that are high-touch/high-visibility in nature, allows for everyone to see progress and status as it happens.

On a Final Note…

It must be said, getting everyone aligned to proper workplace habits can come naturally to those who adopt the scrum process model. It’s not necessarily about having a process, but actually  having a positive attitude and confidence that it will work. Creating that momentum in your day-to-day, will likely come with resistance at all stages of development, but those who are on board, will quickly become visible to the organization and will certainly become the agile champions and leaders.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

 

7 Reasons Why Some Corporations Hate Agile Methodologies

Posted on by

7-reasons-why-some-corporations-hate-agile-methodologiesConventional business wisdom will tell us that we should tell our shareholders what they want to hear so that the price of company stock will rise. This displaces the value that corporations will aim for toward the shareholder and not necessarily toward the customer. This is where Agile methodologies conflict as the goals of a conventional vs. agile mindset are not the same.

Below we will outline how conventional corporate mindset thinking conflicts with that of an agile mindset:

1- Focus on customers over shareholders

As a company you would likely be trying to appeal to both the shareholders and customers, however it’s usually shareholders that will come first and customers second. Based on agile principles and agile mindsets, the priority undeniably reverts to customers first! Everything in the agile value mindset reflects a goal toward delighting the customer and the accepted agile methodologies and processes show much evidence to conclude this is always the case.

2- Perceived Loss of control

The thought that there could be teams that are self-organized and self-managed leaves a sense of control loss by management at any level. Management may argue that if the teams are self-managing, then what is the use for management in the first place. Unfortunately this is a false perception, since management would likely still be needed for areas of business operations that are not covered by the day-to-day of agile processes. 

3- Perceived loss of authoritative rank and power

Most conventional businesses will follow the militaristic approach as the known command-and-control approach to business structure and organization. Companies with a highly vertical (hierarchical) structure being at one extreme and the more flat (horizontal) type of organization at the other end. Those with a heavy emphasis on a vertical structure tend to harbor many of the anti-patterns of an agile approach. Be it either from lack of trust or lack of willingness to let go of authoritative power, many companies that have a top-heavy structure will not be easily capable of converting or adopting agile.

4- Focus on delivering immediate customer value over immediate revenue

As many have noticed the periodic reporting of large businesses, especially those whose stocks are on the market exchange, the revenues that were forecasted must hold up in the later quarters or else face the consequences of lost share prices and market share overall. This places emphasis on how soon work can be done and made billable rather than concentrating on the actual scope and process of work to be done. The best interest of the customer is left behind as resources are stuffed into the work processes, rather than allowing agile methodologies to take their course.

5- Too much learning and too much change

Most who have reached a respectable level within their company whether it be in management or non-management (technical) levels, may tend to sit on their laurels all too often. Although we seem to hope that society is a meritocracy, let’s face it, some people just get to the higher positions based on years of experience rather than actual willingness to continue learning and changing. To this point, there are some who live up to their titles, but others who don’t and wouldn’t care to collaborate with their fellow colleagues either because they have underdeveloped people skills, lack of extensive knowledge, or because it’s seen as too much work to learn and share.

6- Customer value is cumulative while overall benefits only come if done properly in the long run

If there is anything we can’t promise is what will happen in the future. It is highly unlikely that an executive management team will wait to see if there will be continued commitment and support from their existing customers. Since much of what builds up customer satisfaction retention accumulates over time, most companies do not factor that in and will take the shortest path to generating revenue. Building quick untested solutions for the sake of having something billable does not look after the best interest of the client. This extends further to the disappointment of employees who are being told what to do, without buy-in. Some companies would rather sacrifice growth of their existing team synergies to result in high turnovers from unmotivated employees, rather than keep them on-board. This is why at the first sign of lost profits, most companies will take the immediate route of terminating their employees. The reason? It’s the quickest and easiest way to lower costs. However in the long-term it proves detrimental, and usually leads to further “voluntary” fallout where employees lose sense of purpose from the previous setback of layoffs. This affects customer relationships as the level of expertise and direct customer engagement from employees diminish.

7- Increased level of transparency perceived as very risky

Most companies do not share at many levels for fear that the truth may  reveal too much for many to be comfortable with. High levels of transparency bring about a sense of fear that the information provided can be way too sensitive or used against the company. Although transparency may reveal positive and negative aspects of a company and its operations, most companies tend to err on the side of non-transparency to avoid the risk at all costs. This approach of course lowers the level of trust and therefore the level of engagement from customers as they find out from latent communications throughout the project life-cycle.

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

 

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]

 

How to Manage Epics as an Agile Tool in Planning

Posted on by

how-to-manage-epics-as-an-agile-tool-in-planningAs part of a large project, you may have a complex product to develop. Whether for intangible (software, games) or tangible (hardware, electronics), there is a need to structure your backlog by level of complexity and size. Although we typically do not go so far as creating Epics in all agile instances, they can prove to be a handy agile tool if created and used in an organized fashion.

The idea behind Epics are to create a sense of commonality between multiple user stories. It is important at this stage to be sure your agile team members are not using the terms for Epics interchangeably with other terms that could drive confusion in day-to-day communication. But along with this defined approach, all team roles (product owners, business analysts, scrum masters, developers, etc) should think of Epics structures and how they will be used going forward. Here we look at Epic examples in hierarchies for Features, Themes or Requirements.

Features in Epic Hierarchies

One way to look at an Epic is to identify it as the high-level feature. As an example we are referring to the physical features of a landing page on a website. It would have a header, footer, content, images, media, etc. With that you can further breakdown the characteristics with user stories, and then tasks to look like the following:

Epic(Feature) —> User Story —> Task(s)
Example: Header —> As user, I would be able to use a search bar to search the site content… —> Investigate Search Bar functionality

Themes in Epic Hierarchies

Epic —> Theme —> User Story —> Task(s)
Example: Landing Page —> Page Structure —-> As a user, I would see 3 columns… —> Create left column, Create right column, Create center column

Requirements in Epic Hierarchies

If you were developing a series of websites for instance, you would need to repeat a set of requirements for each website. In this case you would likely re-use the requirements as you start each website, and then vary those features. The following example would facilitate re-use of the requirements from one website to the next.

Epic(Requirement) —> Feature —> User Story —> Task(s)
Example: Website Landing Page —> Website Page Navigation —> As a user, I will be able to navigate to all site pages from the landing page… —> Create Navigation Bar

There is no definite way to use Epics, these are simply examples. The variations can be infinite and can vary from team to team, project to project, or product to product. But as we know that Epics are typically large user stories, and represent a level above the user story. One thing that needs to remain stable is that the agile team must agree to structure that makes sense for them.

Using Epics to Stay Organized

Using Epics as an agile tool to organize the stories, can enable easier overview of the different product components (features/requirements/themes). As the sprint backlog can list tasks to be developed by multiple agile working teams on different features at the same time, the overview of each Epic can help the Product Owner prioritize stories and interlinking dependencies with each other.

Another useful setup that helps in the structuring of swimlanes for your Sprint/Kankan boards is to have them created according to your Epics. This makes the horizontal divisions clear on the common groupings. It also adds another dimension to manage on your board, but it certainly would be helpful in larger sized projects.

The most important part in creating structures, is to keep it simple. If there is too much team discussion and confusion where everyone is lost in managing the structure, it means that it’s not simple or clear enough. Of course, if all else fails, keep in mind that Epics are not essential. If your team doesn’t see a need for them to exist in your agile product management scheme, just leave them out, as they might not be required due to your project not being as large or complex as originally thought.

[Image courtesy of Danilo Rizzuti at FreeDigitalPhotos.net]

7 Virtues of an Agile Mindset

Posted on by

7-virtues-of-an-agile-mindsetThere are certain virtues to getting your lifestyle tuned into an agile mindset. For those who actually practice being agile in and outside of their work environment, there’s a lot more to gain on a day-to-day basis. We’re not necessarily referring to just yourself getting to be a better person with the use of agile tools, we’re also talking about getting others around you mindful and self-conscious as well.

Here is a list of virtues that for all those who live and breathe agile, would come naturally. For those who would like to gain an agile mindset, it is an essential set to practice:

1 – Truth

When we have nothing to hide, it makes it easier to be truthful. When we are providing high levels of transparency through the practices of agile time-boxed sessions (planning, scrums, retrospectives, etc.), we are given the chance to keep everyone up to date on our own progress and that of others. Being able to tell and ask others about our progress, issues, blockages, allows others to provide the input they need to keep an agile practices moving toward expected goals.

2 – Acceptance

Every member of an agile team works together to transcend judgement. The team accepts its differences and looks to build products for their engaged stakeholders. This does not guarantee that the product will always be exactly what the stakeholders are looking for. When the product increments are being reviewed, some features might be rejected despite the best intentions of all parties. This means failure has occurred, but not in the conventional sense. Failure that can not be learned from is true failure. But with an agile mindset, we find out why it failed, accept that it happened, but we do not give up on the sole fact that failure occurred. In that sense, we accept failure as knowledge of what does not work, to then build something that does.

3 – Commitment

To be part of an agile team that consistently never gives up, we need be committed to that team on a regular basis. This means we are engaged to the team, and we are learning on a regular basis. Being committed to finding new ways to implement better product features, better processes, better approaches in general. If we leave a team at the first sign of disagreement or disappointment, we are not truly committed.

4 – Respect

Gaining respect is very hard to come by these days unfortunately. This is mainly because some people think that respect comes with their work titles and experience. When you join an agile team, you all are meant to regard each other at the same level. The level of respect moves up as everyone learns to communicate with humility. This means using regular respectful terms like “please,” “thank you,” and “you’re welcome.” Surprisingly, many have forgotten to use these fundamental words when working as a team, but we can observe that teams who have incorporated them into their regular communications, have the utmost level of respect for each other.

5 – Self-Discipline

To obtain a high level self-discipline, one must be able to act on their own initiative. It is part of self-learning and can be enabled by being surrounded by supportive team members. Having self-discipline can help in determining when is the right time to act. We might be tempted to tell others what their flaws are, even in the attempt to help them improve. We may even be tempted to compulsively straighten out someone who is out of line. Having good self-discipline implies that one can hold back in disputes, we see this especially when we can observe others who don’t get carried away with lesser cases of intimidation.

6 – Patience

We are living in a time when we want to see fast results. With agile practices, principles and processes in place we know that we are adaptively adjusting to attaining our goals, at times with the help of agile coaching and mentoring. However, this learning and adaptation also requires patience along with the other virtue of acceptance. When we are confident in the benefits of agile practices, principles and processes, we can afford to be patient since we know that everyone is heading toward the achievement of a common goal. This also helps while taking the time to ramp up on a sprint by sprint basis, or possibly with learning to put into practice, what is learned from agile training courses.

7 – Humility

Much like respect, humility adds to the ability of not only being conscious and aware of others’ contributions, but also showing that we are all part of the same system. When all members take on their agile team roles, there is no sense of judgement if one makes a mistake. The self-organizing team works together to transcend arrogance and sense of superiority, much like the equal importance of vital organs in a living being. One can not say the brain is more important than the heart and so on. With this analogy, we can say that all roles in an agile working team are vital, and no sub-part should be considered more important than the other, as there is no hierarchy.

Solidifying the Agile Team

As we can see these virtues are all interlinked and compliment each other. When adopted by all team members of an agile team, it solidifies the team and makes it incorruptible, stable, and strong. If we look at it from an individual perspective, this solidification still stands, and as we each are sub-parts of the team, we need to work on these virtues ourselves first. When we strengthen those virtues for ourselves, we are better able to contribute to strengthening the team and developing those agile solutions. This is common-sense is often overlooked, since we tend to expect those virtues more from others, and less from ourselves.

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

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]