Agile Benefits

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.

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

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]

How Osmotic Communication Uses The Subconscious

Posted on by

osmotic-communication-uses-the-subconsciousWhile the practice of agile requires a “Caves and Common” setup of teams, there is a reason for it. Mainly it’s to make sure communication is ongoing and regular. This requires a specific setup of office equipment and overall layout within the workplace. The “Caves” aspect refers to a place where some team members have the occasional place or space to work alone for a short or brief period of time, while “Common” is the area where most team members spend their time with the rest of their team for the majority of time in their day.

The Importance of Closeness Among Team Members

Agile practitioners would agree Osmotic communication takes place in most part within the “Common” space as everyone is communicating without barriers whereby conversations and discussions occur freely. The principle behind osmotic transmission and absorption of team members’ conversations implies that we acquire knowledge even if we are not an active participant in any particular conversation. Much like a song playing in the background, even if you don’t know the name of the song, if heard regularly over time, you may just be able to know the melody or lyrics without even trying to memorize them. How this actually is made possible is explained through the way our minds work on a subconscious level. It can be compared to a radio that is always on while the antenna is picking up frequencies at all times.

Much of what we do throughout the day, our daily routines, product purchases, learning habits, and inner thoughts are a result of our subconscious taking over very important aspects of our lives. Although it’s not easily explained, osmotic communication works on a highly metaphysical level. It provides a collective result, a lot of what teamwork provides only when they are in the same location, and not otherwise. This is mainly why the success of an agile team should not be given credit to any one particular member, but rather the collective effort of the entire team.

Osmotic Communication Effectiveness

The key idea behind making osmotic communication effective however, is that the communication should be within hearing distance of any or all team members on a regular basis. Without that, the knowledge sharing and subliminal absorption aspect gets chopped up. Using the radio frequency example, it’s similar to getting only some channels but not all, or a channel with a lot of static. This is how the subconscious mind works, it’s always on and absorbing without effort. It’s important when considering the physical team’s layout, especially in today’s work environment as many teams are known to be located remotely from each other, or with specific members working alone but connected online.

It’s no secret, a team that works together in the same physical space will communicate more efficiently either because of their added ability to listen in to each other’s conversations as well as read their body language. Compare this to a team whose majority of members are located remotely, there’s a big loss on the quality of communication. It becomes increasingly difficult to know if someone is actually being sarcastic or serious without having to see their facial expressions or body language. This is why conflict created among remote members for any particular team could escalate very quickly. They couldn’t possibly be (or become) an agile team with that factor to overcome.

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

Automation is Key to Agile Implementation

Posted on by

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

Agile Ceremonies and built-in automation

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

Keeping it Simple

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

Consistent and Regular Adaptation

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

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

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of Idea go at FreeDigitalPhotos.net]

6 Main Reasons Why You Must Identify Backlog Item Dependencies

Posted on by

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

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

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

1. Reduced Overall Project Risk

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

2. Value-added Efficiencies in Process Workflow

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

3. Facilitation of Priorities

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

4. Early Elimination of Blockers and Time Wasted

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

5. Proactive Conflict Resolution within Teams

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

6. Increased Morale within Teams

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

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

[Image courtesy of tigger11th at FreeDigitalPhotos.net]

 

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

Posted on by

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

Where is Your Company Placing Importance in Their Culture?

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

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

Getting out of Anti-Pattern cycles

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

Learning is Not a Weakness

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

[Image courtesy of stockimages at FreeDigitalPhotos.net]

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]

 

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

 

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