making changes

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

Posted on by

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

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

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

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

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

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

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

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

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

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

How Agile Leadership Can Be Learned – A Quick Guide

Posted on by

There are many organizations need or would like to achieve greater agility. However, in order to achieve it, leadership style and corresponding principles need to be revisited. Therefore if we want agility, we need to demonstrate agile leadership as a result. But how exactly? A global study delivers a behavior-based competency model. The good news is that competencies can be learned.

how agile leadership can be learnedThe Global Center for Digital Business Transformation wanted to find out, what exactly does agile leadership look like. The IMD Business School in Switzerland teamed up with metaBeratung, a specialized consulting firm in Germany, to conduct a global study (Neubauer, Tarling & Wade, 2017). Leaders from all over the world participated while having one thing in common: they operate in a highly disruptive market, which is where organizational agility is considered to be needed the most.

The theoretical foundation relies on IMD’s concept of Digital Business Agility (Bradley et al., 2015) that defines three behaviors that help companies in highly disruptive markets to survive. This study confirmed the relevance of these three behaviors.

Overall 19 expert interviews with digital leaders and data from a global survey with 1042 leaders where analyzed. Beside the three behaviors, four core agile leadership competencies were identified.

Digital Business Agility – The Three agile Leadership Behaviors:

1. HYPER-AWARENESS

This would entail constantly monitoring and evaluating changes in market conditions, developments in technology, and customer needs. It would also include observing trends, identifying and watching dominant factors. Consequently this means that there would be a need to set up supporting processes and investing the necessary resources.

2. INFORMED DECISION-MAKING

This would entail making decisions based on facts and real-time data. Ensuring information is available, analyzed and considered in strategic and day-to-day operative decision making on every level.

3. FAST EXECUTION

This requires prioritizing speed over perfection. Prioritizing faster delivery value over planning and documenting, while ensuring fast decision making and preventing the organization from overburdening bureaucracy.

These three behavioral aspects will equip the leader to steer diligently in volatile markets. However, to lead people and create agility in the workplace, four related competencies are necessary to define the core of agile leadership (HAVE model; Wade et al., 2017; elaborated by Puckett & Neubauer, 2018/ 2020).

Four Competencies of Agile Leadership – The “HAVE” Model

1. ADAPTABILITY

This requires that leader not shy away from changing directions and revising decisions taken when circumstances change, or when new information becomes available. Further, this requires making sure processes, products, and/or services remain flexible enough to include feedback and adaptability to changing circumstances.

2. HUMILITY

This competency values feedback and input from others while being aware one’s own limitations. At the same time this requires the need to keep learning and treating others with equal footing while ensuring inclusion.

3. VISIONARY

This would require leaders to think big, find their vision and wear it on their sleeves while setting the direction and inspiring others.

4. ENGAGEMENT

This competency requires the need to stay connected, to grow and strengthen networks inside and outside the organization. At the same time this would require keeping in regular contact with customers and stakeholders while staying connected to the pulse of the market, such as relevant expertise and knowledge.

Agile leadership can be learned and demonstrating the three behaviors is a matter of effort and focus. Smart leaders will get their teams on board and together will find ways to create and sustain hyper-awareness, to ensure informed decision making and enable fast execution.

Competencies by definition can be learned. Step-by-step leaders can achieve mastery in playing the leadership role and spectrum. Leading agility does not necessarily mean every good idea or measurement has to come from or be managed by the leader. In face it’s quite the opposite. Good agile leaders understand their limitations and they might be highly visionary and very engaged but have difficulties adapting fast enough. Or they might be very humble and adaptable but not highly visionary. Yes, good leaders invest in their own development and grow in each of the four competencies. However, it must be understood that no one can be a star in all four dimensions. Agile leadership means to enable and inspire your people to step up and help build these competencies in your organization overall.

In order to excel in this most important leadership task, agile leaders must invest in their company’s culture to prepare the right conditions for people to grow – and through them attain agility (for more see “The agile Culture Code” Puckett, 2020 b).

Sources:
Bradley, Loucks, Macaulay, Noronha & Wade (2015). The Digital Vortex. https://www.cisco.com/c/dam/en/us/solutions/collateral/industry-solutions/digital-vortex-report.pdf
Puckett (2020). THE AGILE CULTURE CODE – A guide to organizational agility. BusinessVillage.
Puckett & Neubauer (2020). Agile Leadership – Leadership competencies for the agile transformation. BusinessVillage.
Wade, Tarling & Neubauer (2017). Redefining Leadership for a Digital Age. Copyright: IMD, metaBeratung, Global Center for Digital Business Transformation. https://www.imd.org/dbt/reports/redefining-leadership/

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 Ambro 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

Agile IS NOT Scrum!

Posted on by

agile-is-not-scrumThere are certainly many misconceptions that occur with having to implement agility within the organization. The issue becomes even more compounded when non-agile practitioners speculate about what Agile is or for that matter what their idea of what it should be. In our example, this kind of speculation can present a sort of revolving door phenomenon whereby those who are familiar with Scrum, use it to refer to Agile interchangeably. Admittedly, Scrum is a large part of Agile when referring to it holistically, but Agile is not Scrum. However, we can derive some values from Scrum and say that they are synonymous with Agile values. What tends to happen is that many people believe that if they are doing Scrum, then automatically they are Agile. There’s a very fine line to that supposition, but it’s not always entirely true.

Part Of The Whole Doesn’t Necessarily Mean You Are All Of The Whole

For the most part, implementing a part of the whole doesn’t necessarily mean you are all of the whole. As an example we can use the idea of electricity. If some parts of a car (i.e. radio, window system, pumps, battery) are electric, would you say that your car is an “electric” car? Not likely. Even when we do refer to electric cars that are motorized by electric power cells alone, the car isn’t entirely electric per se. This comparison although not an exact representation of the differences in Agile or Scrum, hopefully can give you the level of complexity in the assumption of either one for another.

Agile Is Not Just A Process

For further clarity, there are other mechanisms of Agile in perspective, there is also a mindset and value-driven aspects that should be accompanied with it, not just a process. There’s also other methodologies and processes that can be included or can be complimentary to Scrum (i.e. XP, Kanban, TDD, ATDD) that make a more solid Agile implementation possible. That is not to say that it’s an “all-or-nothing” situation. Further to this we have what is considered to be the Agile guidelines, also known as the Agile Manifesto consisting of 4 values and 12 principles. When speculation and discussion occurs about what Agile really is, very seldom does the conversation include what is mentioned in the manifesto. However, more often, the concept of implementing a Scrum process does. This is where the clarification about those assumptions or beliefs, is very important to distinguish before it’s too late, whereby the decision takes place and is built on a preconceived false notion of Agile.

Agile Expectation And Implementation

Getting the above points out in the open early is not only to assure successful Agile expectation and implementation, but also to bring a more positive light to what can sometimes bring “failures-as-fact.” By that we mean that there are many who have attempted implementing Agile in the workplace, and used a “not-so-complete” method or process into effect. That is to say, they thought they were putting an Agile methodology (or in certain cases what they thought was Agile) in place, then saw it fail, and then concluded “Agile doesn’t work” despite the other flaws.  There are certainly instances where Agile really doesn’t work, or perhaps it isn’t the best solution for your organization, politics and bureaucracy aside. Agile isn’t the cure-all solution to all your organizational woes but can definitely be more fun! Even when it’s not a good match for the organization, not implementing Agile is perfectly fine, it’s not a must, and further to that, it’s not a religion (although it sometimes is perceived as such).

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]

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]

Why Choose Agile?

Posted on by

why-choose-agileIt’s becoming more and more obvious, Agile adoption is growing at an incredible rate, and it has been estimated at roughly 10% annually. Not many who have jumped into adopting Agile have asked the question “Why Choose Agile?” To answer that question we also need to look at already existing methodologies that exist, namely Waterfall. Is it to say that waterfall is bad? or inefficient? The answer is, not necessarily. Waterfall has it’s purposes, and when applied properly it provides all the benefits that are expected from a project that is using it…the key words here “applied properly.” The problem with Agile adoption is that it’s considered to be relatively new, and more often than not, applied incorrectly. So here are the key differences that can help understand and promote the transition from Waterfall to Agile.

1. Process Control

In Waterfall you have phase gates that are defined similar to milestones, and they occur at every stage of the process. For each of those stages there is a request to approve each gate before it is started, furthermore the scope is defined at the beginning and can’t be changed without major impacts. Sure, you can issue a change request, but that likely changes the entire balance of the budget, resources, and timeline. In Agile on the other hand, there is empirical process control where you are redefining the scope based on priority of the preset period of a sprint (2 – 4 weeks). In this way Agile allows the highest value, business needs, and ROI that are realigned regularly. Whereas in Waterfall, you cannot and there is little possibility to change the scope mid-course. Agile therefore allows a team or business to respond to the immediate business needs of their client, thus providing higher value consistently.

2. Triple Constraints and the Perception of Success

The main components to any project are Scope, Time (Budget), and Cost. With Waterfall the Scope is typically fixed, whereby Time and Cost are flexible. Problem though is that even with a Time and Cost change there really isn’t any easy way to determine a cutoff point, and stop teams in the middle of the project while waiting for a client to make a decision. This means that in order for a project to be successful in Waterfall, ideally all 3 constraints would typically need to stay fixed with the addition of change requests. Agile on the other hand provides a way to easily fix Time and Cost while making Scope flexible. Waterfall-minded people will right away spark the question “Will all the scope be completed though?” The answer of course is “not necessarily and that’s ok.” The reason for this is that it doesn’t matter, because in Agile you are already delivering the highest value from your Time and Cost that could ever be delivered from a Waterfall project. Hard to believe at first, but for those who have completed at lease one Agile project, they know this can be attained since the highest priority/value scope is being delivered.

3. Profitability and Customer Retention

Most Waterfall-minded companies will measure their margins from project to project with the intent that each project will need to be profitable. But what happens when a project slips through the cracks and goes into the negative? Going Agile will allow for higher customer retention, after all when you provide higher value through implementing current trends in innovation, accurate and faster delivery dates, customers are more likely to stay with you for the long run. The positive side-effect to this is higher motivation within your teams. This is an added benefit to both supplier and customer since learning curves (performance states) stay intact and will very likely improve when the same team members work together for longer periods of time.

4. Delivery Schedules

Waterfall depends on the entire project to be completed before it can be delivered. This certainly gives the impression to both the development team and the client that the project is going on without end. This of course applies to projects that last longer than a few months. But with Agile, you already built in the expectation that delivery is possible at the end of each Sprint, even though in some cases you may choose not to. The main issue that has never been resolved but almost always happens in Waterfall, is the moment there’s a change request, the client asks for more scope and although they would be willing to pay more for it, they want the delivery date to stay the same. Why not just deliver in increments the way that Agile already requires you to?

There are many more reasons why you may want to choose Agile over Waterfall, but most need to be shown rather than be told what those benefits are. The key point to consider is that Agile adoption should be concrete, and should come with a fully committed paradigm shift in management and teams that are looking to implement all the necessary mindsets and tools that are needed. The most likely and best approach to adopting Agile however, is to jump into it completely and use Agile in itself to inspect and adapt. Taking on a half waterfall and half agile approach will certainly lead to adoption failure.

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

How an Agile Mindset Enlightens the Subconscious Mind

Posted on by

how-agile-mindset-enlightens-subconscious-mindAccording to many experts on the subconscious mind, there’s a very close correlation to our actions from what we think. That is to say, generally there’s a link to what we do because of the way we think, and vice versa. The interesting part is that the subconscious is like a database that is either controlling or being controlled. It controls us on a regular basis and is based on what has happened to us in the past, and can be controlled when we consciously choose to do so. Much like the example of beliefs, if we don’t know why we believe something, but continue to express those beliefs, we are being controlled by our subconscious. Somewhere and at some time, we were led to believe something and have locked it in so that our actions continue to reflect it. Knowing this, we can look to see how the agile mindset enlightens the subconscious mind.

Understanding our Thoughts

If at some point we ask ourselves why our beliefs are there, we may actually be able to change them if we ask the right questions, and refer back to the time when the belief may have been etched into our subconscious. We can however, de-magnetize our thoughts by performing actions that were purposefully and consciously done to overcome subconscious blocks.

Ever wonder why some companies have a culture of having constant meetings, with numerous (and possibly unnecessary) attendees? They may not actually realize that they are wasting each other’s time, and possibly inviting coworkers that could have been best left uninvited so that they could use their time more productively. This leaves many in the workplace crippled from doing their tasks when needed and may need to double efforts to catch up on the more important stuff. To a great extent it comes with learning to self-respect and then in turn that exhibits respect toward others. The best way to respect oneself is to know oneself. You owe it to yourself and others around you to understand the duality of our conscious vs. subconscious influences and the power they can give or take away.

Making Conscious Decisions and Following Through

When we practice agile on a daily basis, and follow the agile values and principles, we may have to take that first step in understanding why we are actually agreeing to do things and think along the lines of what agile represents. Is it because one person had an idea to do things according to agile values, or was it a collective decision? Regardless of the answer, this is the “first step” type of question you need to start asking. Some decide on what they heard, some from their experience, and others go by what is based on faith. If you really want to get your Agile teams set in the right direction, it is important as an agile coach, or as someone championing agile within the organization to ask those questions and get feedback. The result should be from a collective consensus to agree that there is a genuine desire to adopt agile methodologies.

The law of your mind is the law of belief, so all events will follow from that as you work as an individual and as a group in an organization. So as someone practicing agile, you have to make a conscious decision and commit that you will cooperate and apply what is available, and keep it simple and lean. As we know that beyond the agile tools, events, ceremonies, is actual thought process that makes someone do things in a way that promotes the agile values and principles. Have you taken the first step in actually reading the Agile Manifesto? Have you read a comprehensive book on agile to understand some of what the great minds and gurus on the topic have to say?

How This Ties into Agile and our Subconscious

We have a lot to owe to our subconscious mind in allowing us to follow habits whether good or bad. Something as simple as why we brush our teeth, was at some point a conscious decision to properly practicing good hygiene. At this point you probably brush your teeth guided by your subconscious. Putting this into the concept of agile practices with set time-box durations (sprint planning, sprint demos, standup meetings, etc.) we are programming the subconscious as if to say, “this is something that I’m going to commit to doing regularly and repetitively. For those who have been on their umptieth sprint or agile project, they have already realized the almost seemingly thoughtless process when starting and ending their sprints. It can also be said that there’s an almost intuitive insight as to what the consequences will be if things fall outside of time-boxed events or get left out entirely. With that we can see at that point how the action-based practices have tuned the subconscious mind and helps keep in place what the agile values and principles were meant to represent.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

Adopting Agile – Breaking the Cycle of Insanity

Posted on by

adopting-agile-breaking-the-cycle-of-insanityMany personal and work-life goals run on the basis that there will be one expected result from our habits and behaviors. This assumes everyone is doing what they are supposed to be doing and that the track they are on is executed without error. The problem arises when we try to force expected results without actually knowing how to get there. Have you ever tried to get to a destination faster without ever changing your route? This relates strongly to our day-to-day activity. We can assume we do the same thing every time but get different results, and if not we get upset or blame others for it.

There’s a reason why Albert Einstein said “Insanity is doing the same thing over and over again and expecting different results.” Now put that perspective into your work’s daily, weekly, monthly and yearly routine. What you may realize is by definition, we all experience some level of insanity and we are making everyone in our lives share in those expectations while not changing a thing about ourselves. What does adopting Agile offer that could break that cycle of insanity?

Step 1 – Acknowledge Change is Necessary

First we must acknowledge that the first step in breaking away from insanity is to change at least one thing in your routine. That could be anything from when you get up in the morning to when you go to sleep. Perhaps it could be waking up to music, or reading a page out of an inspiring book rather than reading your work emails.

Step 2 – Commit to the Change

Second we need to make sure we consciously commit to the changes we’ve identified for a specific period of time. We need to be sure that nothing or nobody gets in our way to that change and be sure that it’s ingrained in new behavior. Sometimes it may feel like a heavy sacrifice, but just remember that the mind is bound to give up before the body or behavior does.

Step 3 – Observe the Changes and Repeat the Cycle

Once you’ve reached the end of the specific period of time. Sit and write down what were some positive results you’ve noticed over that period. Then do the same to notice the negative ones. Finally think of ways that you would like to have changed in a positive direction. Be reasonable with your expectations, as this should not be a wish list that you would expect results that would take years to achieve. However, it wouldn’t hurt to have a few long-term goals that you hope to achieve in the accumulation of time of progressive periods with positive results. But just be sure you go back to Step 1 and repeat the cycle, and don’t forget to reward yourself for your positive results.

The result of these steps is already a concrete step to eliminating personal insanity. What to do about insanity coming from your peers in the form of complaints and excuses as to why their job, life, or results is a different story. Perhaps let them read this article. If you take on the steps above, you may come to realize is you’ve made Agile a part of your personal accomplishments not just something being used at the office on a project.

Putting Agile Processes to Work For You

To those who are new to Agile, you may ask, what do the steps above have anything to do with it? It’s important to consider that adopting agile is mainly a mindset change. Why not start with yourself. Above we’ve incorporated the agile ceremonies in a subtle way, but you can be assured there are elements of Sprint Planning (Step 1), Daily Scrum (Step 2), Sprint Review (Step 3) and Sprint Retrospectives (Step 3). 

Once you’ve taken these steps and noticed changes, keep in mind that as long as your goals change, so should your behaviors and habits. Goals are progressive and probably don’t always stay the same. If they are, you should probably consider being specific. i.e. if your goal is to gain more knowledge, make sure you specify which domain of knowledge, so that you don’t sit back and become complacent.

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

 

Bringing Continuous Improvement to Project Methodologies

Posted on by

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

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

Why Tailoring Agile Impulsively is Not Recommended

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

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

Setting the Record Straight

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

5 Ways an Agile Coaching Philosophy Enables Agile Teams

Posted on by

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

1 – Showing the team how to be open

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

2 – Modelling what it means give and earn respect

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

3 – Bringing out special talents of each team member

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

4 – Optimizing team performance

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

5 – Keeping a positive outlook in the face of failure

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

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

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

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]