Agile Mindset

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]

Company Culture Is NOT An Excuse! Leverage It For Organizational Agility

Posted on by

The more experiences companies create through agile transformation the importance of organizational culture becomes clearer. It is the number one challenge. It’s true, it could be the very reason why we can’t change, and subsequently why agile won’t work. However, working on our culture will also open the path forward. A closer look at agile organizations reveal that it is culture that builds the common ground and acceptance for agility.

company-culture-leverage-it-for-organizational-agilityOrganizational development has always taught us that change is achieved sustainably when it starts with the people. Agile transformations are no different. On the contrary – the Manifesto for Agile Software Development already brings this focus to the surface. And the more we learn, the clearer it becomes, that organizational agility is a question of how people think and act; a question of organizational culture. Thus, it is not surprising, that agile organizations have little in common in terms of structure and governance (see e.g. Kimes, 2009; Aronowitz, De Smet & McGinty, 2015). Having the right culture helps us achieve organizational agility.

What is Organizational Agility?

Organizational agility is not Scrum at scale. It is not about individual agile methods at all. It also has little to do with table-soccer and couch-corners, nor with dogs-allowed-in-the-office.

Organizational agility is actually about one thing alone: adaptability. The market is changing. Technology offers new possibilities to produce the old things more efficiently, faster, more customer-specific and to develop the new things, demands on the organization or other circumstances that are changing. The organization reacts by adapting. Its strategy, products, processes and structures adapt. If we look at concepts of business agility (according to the Agile Alliance), or the concept of digital business agility (Global Center for digital Business Transformation; Loucks, Macaulay, Noronha & Wade, 2016), we need to add one more aspect to the definition of organizational agility: the ability to identify internal and external changes early on and to derive new opportunities to create new or greater value for customers.

Ultimately, it is about how people work, how individuals, teams and the organization as a whole behave. Do we plan on foresight and focus in on developments step-by-step to explore and learn along the way? Do we monitor what is going on outside? Are we willing to change direction to keep up with the trends? Can we react and execute quickly?

Corporate Culture as an Opportunity, Not an Excuse

How we work, how we behave, that is corporate culture. If an organization wants to become more agile, then it is either the biggest impediment or the most powerful lever.

“The importance of investing in culture and change on the road to agility cannot be overemphasized.” (Brosseau, 2019). Even if it is only about individual agile projects, an organizational culture that does not support agility is one of the most common reasons for failure, as the Project Management Institute (PMI) observes.

So Why Don’t we Tackle Culture?

This is often because culture is understood – or not understood at all – as a spongy, soft, feel-good concept. It’s also because, although we have a vague idea of what an agile culture looks like, somehow hip and start-up-like, it is firstly (and often) so far removed from our own reality and secondly, this image does not offer us any concrete starting points.

Often people in the organization react to the topic of culture with a resigned shrug of the shoulders as an expression of “That’s the way it is with us, it can’t be changed”.

Organizational culture is more often seen as an excuse than an opportunity. Culture is seen as a rigid mass, as a historically-grown, and fossilized skeleton. A culture came into being at some point – in its basic features – and has continuously developed, polished, deepened and specified. An inert mass, but a living one. Culture has to do with people, with the system, with circumstances and structures, but it is more than the sum of its parts. Culture is alive and what is alive develops, and therefore can change.

Culture is a result of collective learning.

The Pandemic Crisis as Opportunity to Tackle Culture

Today, facing a global pandemic that throws us into crisis, we learn very quickly to adapt to new ways. We also learn a lot about ourselves and about the way we work together. We learn a lot about our culture, we learn where its strengths lie and what is holding us back or slowing us down in becoming the best possible company to deal with today’s challenges. We learn new things. Learning is developing.

Let’s reflect on and build on those learnings and allow them to allow us to shape our culture.

For a company’s culture to support agility, three elements are needed which are illustrated in the “Agile Culture Code”, the TEC model (Puckett, 2020) Three Company Culture Elements Increased Agility Can’t Go Without: Transparency, Empowerment and (conditionless) Collaboration.

Please don’t change your mindset!

We humans do not have to change. Actually, we usually behave “TEC-compliant” when we want to solve a problem or achieve a goal privately:

  • Before we get started, we first inform ourselves and make sure that we have access to all relevant information – in order to define and plan the scope and to be able to recognize the need for corrections early on. Once we get started, we regularly check that we are on the right track, that our approach or the solution we develop is working (testing, obtaining feedback, observing reactions). (Transparency)
  • That and the problem we want to tackle we have decided ourselves, we have chosen it and set the goal ourselves. We decide ourselves how we want to proceed, when, where, with whom we will work on it and it is our decision to adapt methods, goals and scope in between. (Empowerment)
  • We look for people from whom we can learn something in the matter, or those who encourage or support us. (Collaboration)

We need to know what is going on and measure our impact. We need to be empowered not only to do things right but to do the right thing. We need to be able to connect and team up with others to focus on contributions rather than roles.

So, no, we don’t need to change. But change has to happen in the organization. To create an environment that inspires us and allows us to bring all our talents to the table and be at our best. 

Image by Gerd Altmann from Pixabay

Sources:

Aronowitz, S., De Smet, A. & McGinty, D. (2015). Getting organizational redesign right. McKinsey Quarterly. June 2015.
Brosseau, D., Ebrahim, S., Handscomb, C. & Thaker, S. (2019). Accessed February 2019. The journey to an agile organization. McKinsey & company. May 2019.
Jurisic, N., Lurie, M. Risch, P. & Salo, O. (2020). Doing vs being: Practical lessons on building an agile culture. McKinsey.com. August 4, 2020.
Kimes, M. What admired firms don’t have in common. Fortune. Released: March 2009. archive.fortune.com
Loucks, J., Macaulay, J., Noronha, A & Wade, M. (2016). Digital Vortex. How Today‘s Market Leaders Can Beat Disruptive Competitors at Their Own Game. DBT Center Press, Plano/Texas.
Manifesto for Agile Software Development. agilemanifesto.org
Puckett, S. (2020). The agile culture code – A guide to organizational agility. BusinessVillage.

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).

Three Company Culture Elements Increased Agility Can’t Go Without

Posted on by

It has been over a decade now that surveys reveal – again and again – the one biggest challenge when transforming to agile: an organization’s culture. No surprise, since organizational agility arises not from doing agile alone but from being agile. So, let’s look at how agility can be anchored in the company culture, so it becomes a lever, not a challenge in achieving agility.

three-company-culture-elements-that-increased-agility-cant-go-withoutIf an organization is agile, it can be seen in how aware they are about trends and developments on the market, how quickly and flexibly they can adapt to the changes they sense around them, and how spot on they come up with their solutions. Structure and process can help to set the organization up for agility, agile methodologies and tool support.

Agility does not happen through structure or tools; it happens through people

However, the heart of agility lies simply in the way people in the organization think and act. What they pay attention to, how they prioritize, how they get stuff done, how well they plan by sight and keep their eyes on the customer. Agility happens through people. By being agile, they form an agile culture in the organization. Intuitive, right? A lot about agility is intuitive. This is why it works so well.

For such a culture to grow and sustain, three elements, summarized in the TEC culture code (Puckett, 2020) are needed.

We all know how to best solve problems. We’ve done it since we learned how to walk

Imagine a project you would like to realize. Any project, business or personal. Often, the very first thought after we come up with an idea is “Can I do this?”

To answer this question, we think:

  • Do we have enough knowledge to understand what we are getting into?
  • Do we have access to all relevant information and data to validate that we are taking the right steps?
  • Do we know what success looks like?

-> This is our way to create the TRANSPARENCY we need to see this through and to self-correct and steer ourselves along the way towards success.

Behind the initial question if we can do this, lies another basic condition. Some very basic thoughts:

  • Can we take that decision?
  • Do we have the freedom and the means to take on and execute the project?

-> This is our way of ensuring that we have full EMPOWERMENT.

Lastly, we make sure we are not on our own. We activate our network or build a network with people that we can use as a sounding board, bounce ideas off, learn from and ask for support if needed.
-> We ensure that we have the COLLABORATION we need.

The common denominator in agile organizations

This is it. This is the common denominator of agile culture –> TEC: Transparency, Empowerment and Collaboration. Manifested as pillars of a company’s culture, they come each with three unique aspects, each that require attention.

The three pillars and nine facets of the TEC culture code

Pillar 1: Transparency

  1. Information: transparency with information and data

Direct line of sight to the customer, access to information about developments in technology and market, knowing what the competition is doing, etc. goes in line with transparent key performance indicators of the company. This allows us to think strategically.

  1. Intention: transparency with intention and plans

To make sure we align forces and act as one organization, we all need to understand the organization’s purpose, its intentions and plans. This way we can channel ideas and align our efforts with the current corporate priorities.

  1. Effect: transparency with results & impact

Feedback is key to be able to optimize solutions on evolving customer needs. A direct line of sight, where possible, allows us to see firsthand how our work is perceived. Knowing where and how the different tasks we are working on play a role, we can self-steer to have maximum impact on value creation.

Pillar 2: Empowerment

  1. Freedom: freedom to adapt and create

Work is more fun if we are in control and can decide or at least influence when, where and how we work. We are also more creative if we have the freedom to try things differently or experiment with something new. Freedom also allows teams to quickly adjust and adapt to changing circumstances, fostering adaptability and speed throughout the organization.

  1. Enablement: empowerment to take charge

Empowerment means not only deciding how to do things right but doing the right thing. Given the transparency that provides a clear line of sight to the customer or access to data in combination with knowledge of the strategy, every team can act as an autonomous unit that works to generate maximum value. Ideas are implemented fast, adaption happens where it is needed most, at the contact point to the outside (e.g. customers).

  1. Ownership: ownership, biased toward action

Where we used to hear “not my job” before, people are now committed to achieving a goal, not to filling a job role. Entrepreneurship is fostered when people take initiative and have end-to-end responsibility.

Pillar 3: Collaboration

  1. Exchange: collaboration through exchange and sharing

One advantage an organization has, is that it can achieve mastery, generate new knowledge and ideas by connecting the many minds within, fostering exchange and sharing.

  1. Contribution: collaboration through contribution and flexibility

Modern organizations focus on value creation. This requires us to think about our skills and how to add value with them. It requires commitment to doing your best (when and where needed), not on doing a certain job in a certain team in a certain role. It also requires investment in building flexible networks that form temporary and open teams to achieve different goals.

  1. Learning: collaboration through learning and growing together

To advance together as an organization, we must learn together. The starting point is taking time and extending trust, to openly talk about mistakes and to learn from them, together. Collaboration also means to support each other’s success and development, and to challenge each other to leave our comfort zone. Growth happens if we take risks and challenge the status quo.

We are the culture!

Achieving the three TEC elements is what organizations strive for. However, we are the organization. We are the culture. Look at your own space to maneuver, at your area of responsibility. What can each of us do to increase transparency, to empower others and to improve collaboration to the next most intense, and most flexible level?

Source: Puckett, S. (2020). THE AGILE CULTURE CODE – A guide to organizational agility. BusinessVillage.
Image courtesy of IndypendenZ at FreeDigitalPhotos.net

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).

The Agile Mindset And Why It’s Important

Posted on by

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

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

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

Why Is An Agile Mindset Important?

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

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

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

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

How Do We Adopt And Develop An Agile Mindset?

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

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

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

Is Agile Practice The Key to Work Happiness?

Posted on by

is agile practice the key to work happinessWhen you think back at all the times you’ve enjoyed what you done. You were likely and most certainly had that overwhelming feeling of accomplishment, like there was purpose to what you were doing. It may have started when you were a young boy or girl, at home, on the beach, in nature, or at the park. If you were to imagine or recall what it was that you were doing, it would have probably been in the form of a game, involved friends, or the use of a repeat sequence of movements or patterns that stimulated your creativity and ideas. Something along the lines of building a sandcastle, piecing a puzzle together, or some other form of genius process in the making.

We can relate the practice of agile and the agile mindset to almost a similar way. If you don’t get that feeling in what you are currently doing, then something is likely missing. Yes, we’re aware, Agile practices are done at work not in our personal lives. If we read between the lines on what Agile principles will advocate, we learn to see that there’s a certain pattern to stimulate the creative process. Is it possible to make a certain “work” process enjoyable? Many of us might think of our work as mundane and repetitive, but Agile doesn’t have to be! The context in which we think of our work is always a factor in which we can enjoy and be happy about what we do.

The following are just some key thoughts on how you change your perspective and kick your daily work life routine into something you enjoy and bring out the kid in you:

1- Think of work like a game, not actual “work”

Remember the example we gave above? We’re saying, you don’t have to be doing something just because someone tells you to do it, do it because YOU WANT TO DO IT. Better yet, the Agile practice is filled many ceremonies (Sprint Planning, Daily Scrums, Sprint Demos, Retrospectives, etc.), and those are opportunities to turn it into a game, a game that is continuously improving. One of the things we see in sports, is that the actual game, the event of one team vs. the other, never just ends there. The end result of each game played (much like an iteration) is part of the process, and the team (and individual athletes) is looking to play future games a little better over time, and so on.

2- Find purpose in the actual work you are doing

Do you like the industry? Do you like product you are developing? Do you like the people you are working with? If you’re having a hard time answering these questions, you need to stop and take a look around you and take a mental check on what you are doing there to begin with. Half the stress you may be subjecting yourself to is the actual environment you are putting yourself into, not necessarily the actual work itself. Agile principles refer to “people”-like values. If you are not a social person, you might not be liking what you are doing, and it’s important to consider that. Much of what is happening today is remote-work, which includes most teams working at home alone and without any form of social interaction. Probably the most of what remote workers get are Skype and Slack messages and phone calls. If you are looking to be Agile the first thing you should be looking to do is be more social and have more face-to-face interaction. If you are working remotely, it might be difficult, but using that laptop camera during meetings may definitely enable more social aspects and sense of community with the rest of your team.

3- Celebrate achievements and milestone acknowledgements

Much of what we can get out of building purpose and happiness in our work lives can be stimulated and maintained by putting in rewards and trophies. Much like any game or achievement, you feel a lot better when you get to the end while acknowledging what the team completed and achieved the end goal. Perhaps this can be used at the end of each Sprint? or each product release? why not? All that time and hard work, should be rewarded with any form of accomplishment. Many companies are learning that this is one of the best ways to build that sense of purpose into their cultures. That is not to say that these types of rewards are necessary, as we mention above, you need to have your own intrinsic reasons for purpose and happiness in the workplace, much like you do for your own personal goals.

Anyone telling you what YOUR purpose is at work is futile, and will only lead to more dissatisfaction. The cycle will create more and more levels of disappointment and perhaps even more levels of conflict. One of the easiest ways we can advocate happiness in the workplace is to take the process and turn it into a game, but make it a game that everyone can play creatively, and take seriously. Sure there’s always a few laughs that are encouraged along the way, but make sure you have something in place that can be sustainable and enjoyable for all. If you are already practicing agile methodologies, your easy bet is to make those into games. One of the more common ones we’ve seen already is Planning Poker during Sprint Planning, but as most things in life, we can change practically anything that involves teams into something with increasing levels of fun.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

Warning! Parkinson’s Law in Agile Projects

Posted on by

One cannot avoid unseen forces in effect when agile in place. That said, when practicing Agile you must be aware of the “Laws” at work. We’re not necessarily talking about the ones that bring about the police, judge and jury if you break them. When looking at Parkinson’s Law, we’re talking about a law that you can’t avoid whether you like it or not. 

What Is Parkinson’s Law? And How it Works

Parkinson’s Law is all around us, and it’s part of our everyday lives, but since we find it to be a natural progression of what is constant in our day-to-day, we think nothing of it. So it’s time to wake up! What about Parkinson’s Law? Well it states that “work expands so as to fill the time available for its completion.” That is to say, we usually think of estimating work (in whatever form you decide), to the extent that we know about the available resources. If you were asked to go fill a cup of coffee for someone, or yourself for that matter, would you be likely to fill it to the top, or just halfway. Sure we can think of the times we would fill it halfway, but more often than not, we fill it to the top. So we’re not saying Parkinson’s Law is an absolute or that it happens 100% of the time, but it does certainly happen often.

How Can You Spot Parkinson’s Law at Work?

avoiding-parkingsons-law-agileUsually when we estimate during planning sessions, we may be lead to fill up the time we have to do something, with the time we have available. So let’s think of this on 2 levels. In sprint planning we naturally fill in the Sprint with the story points based on our average velocities from previous sprints. Now that’s where Parkinson’s Law works well. And that’s actually why we use story points, to remove the concept of time, and falling into traps, not just Parkinson’s Law. But say for instance, someone asked you to estimate a Story (or Use Case) in real time, and imagine that you were somewhat influenced previously (or at that very session), where someone said in low-key that you had about 3 days to do it. It may very well take 2 days to complete the work, but are you being rational at that point? Or are you going to really take some time to figure out how long it may actually take? Any task, no matter how simple or compact, deserves a fresh set of thoughts and ideas to assess it’s level of complexity. Reason being, you wouldn’t want to over (or under) estimate a task if it truly wasn’t the time it could’ve actually taken.

What Are the Consequences?

Assume you estimated every task you had with what your colleagues told you is the “standard.” You could very well just go with the “standard” times, or better yet you may give yourself the excuse that you didn’t have the time to run through the actual requirement, or the task seems so simple, it shouldn’t take longer than the “standard.” Think about what this means with regard to the overall value of a project. The concept behind which sprint planning, depends on your flexing the metaphorical estimation muscles. The more you practice, the better you will become at being increasingly accurate. With unrealistic estimates, you may actually inflate budgets, and the perception of waste will be greatly increased, and the level of competitiveness drops. Many teams can fall victim with this Parkinson’s Law at work, when many tasks that shouldn’t take very long, end up being logged with double or triple the time it really took. You may be able to get away with it sometimes, but what if your client isn’t that naive?

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

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]

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]

Agile Team Behavior: Kindness Is Not a Sign of Weakness

Posted on by

agile-team-behavior-kindness-not-sign-of-weaknessMany in today’s corporate working environment are encouraged to show signs of confidence, strength, and leadership. The problem arises when it’s said and not shown. Some people tend to make up their own definition of leadership, or take on roles from fictitious movies. Much like leadership, there are many types: tyrannical, autocratic, cross-cultural, or servant, etc.. As we can see there’s a lot someone can interpret as proper forms of character traits. Some might say that because someone likes to tell someone else what to do, that they have a strong sense of leadership. This is false, and is not necessarily the case as history will tell.

So when it comes to drawing conclusions about someone’s leadership style, the important factors to consider are the results they provide. Do they promote failure or success? Is that very person creating a lot of adversity? Sure sometimes adversity is healthy in working environments that require change or innovation. It builds up ideas and brainstorming on how to resolve problems. But otherwise, you may be staring down an inevitable rabbit-hole of high employee turnover in the workplace. For those who try to take the easy way out, the bullies, the power-mongers, they will likely search to find easy targets to blame or throw under the bus when things don’t go their way. With today’s widely diverse and geographically distributed workforces, this could also play out to be a recipe for disaster. Stating the obvious, there’s a big difference in cultures from one country to another across the world. Even-more-so, there are huge cultural gaps with neighboring countries that share the same border.

In previous articles we’ve advocated about the agile mindset, something that can be a bit of a culture shock for those who are new to agile especially. When a working environment with constant power struggles or command-and-control tactics, receive new members that are of the agile mindset, the newcomers may be perceived as passive, non-assertive, and weak. This may be the foremost biggest challenge to bringing a company culture to becoming agile, especially when agilists are outnumbered. With these perceptions there are inevitable easy outlets by those who don’t want things to change, and lead to dismissing agile implementation altogether.

This brings us to the “kindness as a sign of weakness” perception. Socially it is everywhere, the aggressors are always seen as the strong-minded, or heroic only to be hidden from the truth, when they are in fact bullies. So what does this mean for the humble, the kind, the polite, or more importantly the “professional?” When faced with such adversity, are they actually the ones with little or no confidence? When someone is kind to their fellow bully co-workers, this is not a weakness but a sign of perseverance, and by far it is the ultimate sign of confidence. Only a confident person can put up with the bully archetype, not be intimidated, and continue doing what they enjoy doing without the disruption of their weaker counterparts.

In much of today’s society, what keeps our minds at ease is to know that there is much more of the kind and humble, than there are those who are bullies. What is important for those in agile circles, is to make a sincere choice, if the workplace is filled with those who like to harp on those who are perceiving others who are kind and humble as easy and “weak” targets, make the choice to decide moving over to another workplace or company that appreciates you. Your strength will be appreciated in like-minded circles.

[Image courtesy of Ambro 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 Micro-Aggressions That Break Synergy in Agile Teams

Posted on by

5-micro-aggressions-break-synergy-agile-teamsAs we’ve revealed in a previous article How To Recognize Team Synergy in Agile Teams, a team builds up its stages of forming, storming, norming and performing over time. It is in every team-member’s best interests to keep the synergy in agile teams at a “performing” level in order to carry out the tasks and deliverables set out by the project stakeholders. But as one of Niven’s laws states “It is easier to destroy than to create.” With that we’ve identified some common Micro-Aggressions that can easily destroy the team dynamic that took so much time to build up.

Micro-Aggression as described by psychologytoday.com, are the everyday verbal, nonverbal, and environmental slights, snubs, or insults, whether intentional or unintentional, which communicate hostile, derogatory, or negative messages to target persons based solely upon their marginalized group membership.

Below are some examples of common micro-aggressions that you may find the workplace, and should take action to diffuse if they become increasingly used by team members. As you may notice there are many possible situations where dialog can take the form of joking, or sarcasm in a way that the target may even smile, laugh or shrug. However, given that these statements reinforce stereotype myths they can actually be considered as micro-aggressions to some degree:

1 – Saying someone is too much of another type of ethnicity to be the one they currently are a part of

This could be in reference to one’s physical skin color, dietary or cultural preferences, or sexual preferences. Similar expressions can also present themselves when someone tells another “I didn’t know that [someone of a certain ethnicity] would like a certain food or activity [from another ethnicity].”

2 – Over-complimenting someone because it was a surprise for someone of their gender, status or ethnicity

There may be instances when someone is given a promotion, or new assignment that someone else may have wanted. Similar situations can present themselves when someone of a certain gender takes on a position that the opposite gender would typically be “expected” to have. An example of what can be said in this type of situation is “who would have thought you’d make it to the Senior Director position after just being a Manager.”

3 – Recipient of confidential information is told that someone of their status or position would not typically receive it

This situation will typically present itself when someone in a senior-level or superior position tells someone who reports to them, that they were lucky to have that “secret” information, as someone at their “level” wouldn’t typically be a privileged recipient.

4 – Being told a seemingly positive remark in a sarcastic or ambiguously negative tone

There are numerous times throughout the day where team members may tell their colleagues short and seemingly positive remarks like “Good Luck!,” “That should be fun!,” or “Yay!.” As you may notice, those expressions can be said in a truly genuine positive light, but they can also be said in a totally opposite regard.

5 – Being asked the big question “What are you?”

This question is clearly ambiguous and takes the inquiry too far to be comfortable, and it presents an entire list of potential issues that can make the target feel inferior. The “what” is probably meant to probe the target’s ethnic background, but it can certainly be taken to ask about someone’s sexual preference, gender, or in some circles their social status. The point here is that the target can be taken to be inferior to the one asking the question.

When questions of a micro-aggressive nature are asked, it’s important to realize that the person asking the question may not realize they were being an aggressor to begin with. We all have a part to play in diffusing these types of micro-aggressions, starting with ourselves. This is to say that we all may fall into the trap of asking or partaking in a micro-aggressive statement and may not have realized, intentionally or not, that we may have made someone a target in the process. Reading up or talking about the topic in the workplace may be a good first start to identifying the appropriate types of dialog to have around teams with diverse backgrounds.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

5 Guidelines From Agile Modeling for Agile Best Practices

Posted on by

agile-modeling-guide-agile-best-practicesThroughout the life of project there are many potential pitfalls to implementing and practicing agile. As the agile principles and values are put into practice it’s important to take steps that keep the path of agile best practices for which you are looking to benefit from. The use of Agile Modeling is an excellent way to integrate agile principles and values that can complement almost any other agile methodology (i.e. Scrum, XP, etc.).

Agile Modeling components don’t all need to be implemented to make your project agile, however the more you can put in place with thought and importance in each project situation, can provide solid benefits over time. Most importantly, they provide a good framework to building an agile mindset, and integrate seamlessly in an ongoing agile project. The following is a short list of some components:

1 – Active Stakeholder Participation

As with any agile project, the best way to guarantee success is to make sure your stakeholders are involved at all times. The Product Owner usually is the voice of the stakeholders, and we would all hope that it is always that one person that could speak for many. The importance of “Active” is the key to success. There can be times where stakeholders come out from hiding and suddenly become a decisive voice (make or break) in the success of a project. Late stakeholders that become active at the end of a project open big risks as it is the most costly point at which to make changes to accommodate their expectations.

2 – Document Continuously and/or Document Late

Notice here that we mentioned “and/or,” as an approach to documenting your deliverables. It likely will depend on the type of solution and dependencies of functionalities between features as deliverables. That is to say, it’s always best to document continuously so that you don’t have to wait until the last-minute to remember which features were implemented in your solution. As expected in an agile iterative nature, you are looking to deliver a potentially shippable solution at the end of each sprint. This would require regular documentation revisions if the features were to change and evolve drastically over the course of numerous sprints.

Admittedly it sounds contradictory, but this is where it would be best to document late, since it would be less wasteful if you were to document your deliverable once all features were integrated as much as possible. Particular attention needs to be placed on the nature of the product and development. As in the case of software development, releases occur frequently, some major and some minor. Some consideration as to what will be major and minor can allow for less waste when it comes to documenting.

3 – Iteration Modeling

As the initial part of any iteration, we expect take some time for planning. Usually that time will vary from a half day to an entire day depending on the duration of your iteration/sprint. Iteration Modeling outlines the features and design of what is expected to be delivered by the end of the sprint. Some features may end up being developed in sub-parts over a number of sprints, as well as entire parts. The importance here, is to outline how modular some features may be to the rest of them. With that in place, it becomes much easier to prioritize a sprint backlog, which brings us to the next point.

4 – Prioritized Requirements

There are many factors that go into prioritizing requirements, but the one starting point to attaining this is to actually have a backlog (or list of work items) in the first place. In most cases this Sprint Backlog will come from a much larger list called the Product Backlog. As many practitioners soon find out, prioritizing is a key activity that requires identification of numerous factors such as: ROI, risks, stakeholder needs, functional dependencies, available resources, etc.

5 – Single Source Information

If there is one thing that can cause duplication is a highly bureaucratic and disorganized framework from which an organization is set up. Although seemingly simple, having one single source of information is a major challenge for an organization. Many will point to 1 wiki page as a source of information, whereas other departments try to set their own identities and create their own versions of information that gives them a sense of purpose. From an agile project approach, it is extremely important that all parties learn to use one source of information so that it is updated in 1 location to reduce redundancy and waste.

Many companies today, still strive to revise documents of the same content, but in different locations every time there’s update. Beyond just the internal operations, the complexity of multiple sources increases when working on a project where the client looks to use their own sources of project information in conjunction with that of the vendor’s information. In this scenario, duplication is not efficient and is highly wasteful throughout all organizations, as everyone struggles to find out which is the latest version of the code, documentation, template, etc.

More Agile Modeling Guidelines

From an Agile Modeling perspective there are many more components that make up the framework of agile best practices. The important factor to consider is that it will not be an overnight implementation, nor will it be an overnight success. It takes a considerable amount of time and resources to make an agile system work, but unfortunately, not many want to invest, and expect instant gratification. As history will show, even the concept of instant plug-and-play came with a series of bugs and fixes.

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

The Values of Being Self-Made For Agile Learning

Posted on by

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

Why is Being “Self-Made” Important?

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

Being Part of a “Self-Made” Agile Team

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

Wanting to Experience: The Key to Learning

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

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

 

How an Agile Approach Boosts the Value Cycle

Posted on by

how-agile-approach-boosts-value-cycleWhen it comes to team and company performance, many old-school thinkers and business-people look to how they can cut costs. Not their fault, but to some this is the only way they can leverage their stagnant knowledge, instead of taking on an agile approach and promote increased learning. This is likely where some are labeled as “the banker” or “the accountant.” There is recent evidence that shows if we perform on both sides of the finance and marketing fence, there is a higher level of progress and efficiency overall on spending, innovation, and revenue.

Conflicting Views: Cost Cutting vs. Value Creating

There are two strategic views that play within this spectrum; either cutting costs or creating value. Cutting costs creates the concept that there is a finite source of value or income that must be compensated for. Creating value on the other hand, breaks the barrier of thinking there is a cap on source of wealth and ideas. Certainly anything to be created requires that costs be incurred, but that is not to say we must limit investment if all the signs say GO!

Cause and Effect of the Value Cycle Explained

This brings us to the traditional vs agile project standard. When you look at a traditional project, the premise is set at the beginning of the project that it will have a finite timeline and budget. In an agile project you typically don’t have these restraints because the primary concern is about product and how to build value into it. All else if done properly will generate an infinite level of return. Why? Because a product being developed in an agile environment has the implicit expectation that with time there will be more to learn about the market, product composition, and technology that will allow for improvement. Reduced cost is a byproduct of the value cycle, since there’s usually a way to produce something with higher durability making it less prone to defects and complaints. This in turn satisfies the market and creates more demand and increased prices. Volume will also increase, and as we know that also drives down the maintenance or per unit costs.

Value Cycles Are Not Meant to be Broken

The value cycle never ends, hence why typically we look at an agile project as infinite as well. Actually the term “project” can be seen as a sort of oxymoron statement when putting words “agile” and “project” together. But that is for you and your peers to debate. When we look at the constituents of the value cycle right from the beginning where we determine requirements all the way to market release, maintenance and feedback, we can see very clearly that the market isn’t picky about how a product with unique features will look like at first sight. If someone claimed that a time-machine would take up the space of a city block, many would not be concerned. They would still look to use the product and would probably line up along a few city blocks to be the first to use it. This example may be a little far-fetched, but it is used to drive the previous point into context.

Why re-iterate?

As you can see value cycles and agile are very closely tied. They are based on an iterative process. If you believe you understand a concept upon the first try, there is a very high likelihood you missed a few points. If you take the first attempt, you may be successful, or you may not. However you took the first step, and there should be no reason to stop there. There can always be better, there is never any reason to stop improving.

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

 

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]

 

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]

 

Agile Coaching and Mentoring – Wisdom Explained

Posted on by

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

Coaching and Mentoring – What is the difference?

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

When is the Coach a Student?

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

How Does Knowledge Transfer into Wisdom?

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

Creating Genuine Purpose to an Agile Coaching Philosophy

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

5 Signs Your Agile Team Roles Might Be Falling Behind

Posted on by

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

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

1 – Velocity is fluctuating and unpredictable

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

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

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

3 – Overly dependent on fill-in roles

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

4 – Loss of transparency and hidden agendas

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

5 – Repeated anti-patterns that were identified in Retrospectives

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

What to Expect From the Team

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

[Image courtesy of iosphere at FreeDigitalPhotos.net]

10 Ways an Agile Mind Uses World Class Thinking

Posted on by

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

5 Ways to Recondition a Waterfall Mindset to an Agile Mindset

Posted on by

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

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

1 – Keeping your priorities in check

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

2 – Knowing the difference between variable and fixed timeline

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

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

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

4 – Dedicate yourself to agile training in all forms

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

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

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

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Bringing Continuous Improvement to Project Methodologies

Posted on by

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

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

Why Tailoring Agile Impulsively is Not Recommended

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

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

Setting the Record Straight

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

 

Agile vs Waterfall – How an Agile Lean Approach Reduces Time to Market

Posted on by

When creating a product that we are excited about, we might already start to think about how to get it out to the market as soon as possible. When taking a lean approach if we were looking at it in terms of project methodology (agile vs waterfall), it is certainly quicker than waterfall. This however raises the question about what the primary features of your product will be. If you or your team have already wandered off into the abyss of creativity, and started to think of every possible feature, it’s fine to do so (without wasting too much time). But ultimately to get started, it’s important to get back to thinking about the core.

agile-vs-waterfall-how-an-agile-lean-approach-reduces-time-to-market

The first step to accomplishing this is to think of scaling your product with a list or series of MMFs (Minimally Marketable Features) to create your MVP (Minimum Viable Product). This could be more difficult to do than you might think. If your team has already gone really far in the amount of features your product will have, you’ll have to take a few steps back, and do some agile release planning with the intent of categorizing them (or backlog items) in the following order:

1 – Is this feature adding to necessary working functionality?

As part of scaling back your product to be a minimum viable product, you have to think about the basic features and functions. In today’s technology enhanced world, we may feel blinded to the extreme amount of features that we get when buying something like an electronic device. Some may come with a user guide that, let’s admit, only 10% or less of buyers will actually read. Many just need 5% of features that the product can provide. That is not to say that the other features aren’t useful, but you can easily appeal to the larger part of the market that is looking to use the product for the majority of uses. For example, think of a product like the smart-phone and think about how many people actually use it just for talking or dialing numbers to call people. Most consumed the majority of the device’s use by texting and emailing, and reading. Imagine if you spent 90% of product development time (or project management life cycle) on a feature that is only used 5% of the time. You wouldn’t be attracting much of the market. But we have to admit, if you bought a smart-phone, it’s very basic function would be to make or receive calls. Using iterative deliveries such as what we find in sprints, can allow for those quicker more frequent releases.

2 – Is this feature marketable once implemented, and what is the perceived ROI?

There should be some considerable market research for the product you are willing to produce. More importantly, the research should also be able to provide the level of market demand. With that level of market research, the Product Owner and Agile Business Analyst should be able to determine the short to long-term benefits of that product once begin it is released to the market. This could be listed out as ROI for each of the features being planned to include in each iterative release of the product. For example, Feature 1 = $10,000 returns, Feature 2 = $5,000, Feature 3 = $100. By looking at the list you will immediately know that developing Features 1 and 2 will give you a return of $15,000. Especially if you knew that your project could only budget for development of 2 features.

3 – How soon can it be completed? implemented?

The time to develop and release a new product will ultimately determine how fast you can get your product out to the market. The key will be to take the features that would provide the highest level of return for the lowest amount of development time or cost. This might not be a simple exercise, but with proper analysis and calculations, your agile team, should be able to decide which those features give the highest result. This reduces risks in multiple forms. Primarily the risk of waste is reduced, such that the possibility that the product feature becomes obsolete before it is ever released is diminished being sold and in the hands of your consumers.

4 – Is there a foreseeable or complimentary enhancement release that can easily be added to this feature?

If you are working on Version 1 of your product, you may already realize that a few more plug-in features can be added to the product with minimal effort in future releases. Your competition may already be looking at those added features before you get them out to the market, so it would be important to consider carefully before you develop your first version. Having a well laid out agile release plan, would allow you to see if the market will be looking for an update to your product relatively quickly. This would also depend on the nature of your product, since software is relatively more easy and less costly to update and distribute than a piece of hardware.

5 – Can the product be easily adopted or used?

With reference to point 1 above, if you are developing a product that the market can use right away, that is certainly a plus. The other side of the coin is, whether or not the consumer-base is able to use your product right away and would it fill an immediate need. The intent to having your product out to the market quickly, is to be the first product that the market will adopt and hold on to for future updates. If there are many competitors out there producing similar featured products, you have to compete on the level where you are releasing the most amount of updates or upgrades in the form of additional features so that the perceived benefit of your product is the highest among your competitors. If you keep in mind, the higher the perceived benefit, the market value will go up. With a higher perceived value, there is an automatic willingness for the market to pay more for your product, and that gives higher ROI.

Taking all points into consideration with an agile mindset and lean tools can more easily facilitate the team’s ability to get your product out to market. Since after all, the best way to consider simplifying all product options and how to simplify them further, is more easily attained by engaging the experts themselves.

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

How to Prioritize Backlogs with Agile Teams

Posted on by

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

How do we know what needs to get done first?

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

Can We Determine the Difference Between Urgent and Important?

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

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

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

Recommended Tools:

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

How do we narrow it down?

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

How to Recognize Team Synergy in Agile Teams

Posted on by

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

Team Synergy is NOT instantaneous

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

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

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

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

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

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

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

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

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

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Welcome to The Agile Times!

Posted on by

On our site you can find a series of expert opinions, advice on Agile insights, book reviews, and software usage tips, as well as training certifications and recommendations. Bookmark us now and join our Newsletter for regular (but not overly annoying) updates. 

Feel free to join us at our other social sites:
   twitter-logo    linkedin