Author: The Agile Times

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]

How to Manage Epics as an Agile Tool in Planning

Posted on by

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

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

Features in Epic Hierarchies

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

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

Themes in Epic Hierarchies

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

Requirements in Epic Hierarchies

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

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

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

Using Epics to Stay Organized

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

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

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

[Image courtesy of Danilo Rizzuti at FreeDigitalPhotos.net]

7 Virtues of an Agile Mindset

Posted on by

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

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

1 – Truth

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

2 – Acceptance

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

3 – Commitment

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

4 – Respect

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

5 – Self-Discipline

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

6 – Patience

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

7 – Humility

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

Solidifying the Agile Team

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

5 Ways an Agile Coaching Philosophy Enables Agile Teams

Posted on by

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

1 – Showing the team how to be open

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

2 – Modelling what it means give and earn respect

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

3 – Bringing out special talents of each team member

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

4 – Optimizing team performance

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

5 – Keeping a positive outlook in the face of failure

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

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

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

Essential Agile Books (Must-Reads)

Posted on by

The following are books written by the most senior and leading experts on Agile. They provide information for those of all levels of Agile knowledge. Reading all (or most) of these books would provide a solid foundation of Agile principles, processes, and methodologies.

 

1 – Agile Software Development: The Cooperative Game (2nd Edition)
Author: Alistair Cockburn

Review: Written by a legend in the agile movement for software development. This book takes on the approach of developing software as a game. It provides the simplified way to look at providing effective, high quality software while building in high value features that the client will recognize for return on investment.

  Agile Software Development
BUYNOW

2 – Agile Project Management: Creating Innovative Products (2nd Edition)
Author: Jim Highsmith

Review: Written by Jim Highsmith, another agile legend in the software development field. His book puts forward all you need to know to get started from a project management point of view. It is not only limited to starters, but also for those who are well versed in agile processes and practices. The anecdotal aspect that Jim provides is also a very good learning point for his readers since it gives a situational perspective, not just theory.


Agile Project Management
BUYNOW

3 – Becoming Agile: …in an imperfect world
Authors: Greg Smith, Ahmed Sidky

Review: This book gives you a starter view for those who haven’t yet been on agile projects. Taking on the approach of giving pilot project point of view while implementing change from more traditional processes. It provides methods in which to prepare and plan feasibility of a project and to adopt them so that your team eventually becomes a fully agile operation. A must for all agile management and development teams.


Becoming Agile
BUYNOW

4 – The Art of Agile Development
Author: James Shore

Review: This book gives multiple points of view for an agile project. A book you can share with all stakeholders for your agile project. It provides insights whether you are a manager, business analyst, executive sponsor, customer, developer, and/or tester. As we commonly see agile from scrum processes, this book takes on extreme programming as their method of explanation.


The Art of Agile
BUYNOW

5 – Agile Estimating and Planning
Author: Mike Cohn

Review: Written by an agile expert, Mike Cohn. Whether or not you are getting started with agile or not, this book is a must have to understand and refine the process on how to estimate and plan for your sprints on any agile project. It will give you insights on story creation, story points, and ideal hours. This is a companion book that can be referenced daily for managers, developers and business analysts alike.


Agile Estimating and Planning
BUYNOW

6 – Lean-Agile Software Development: Achieving Enterprise Agility
Authors: Alan Shalloway, Guy Beaver, James R. Trott

Review: Written by an Agile/Lean/Kanban expert, Alan Shalloway gives multiple lean perspectives while describing how to scale agile. This book demonstrates how Agile and Lean concepts are tightly linked and give optimal results for software development.


Lean-Agile Software
BUYNOW

7 – Agile Project Management with Scrum
Author: Ken Schwaber

Review: Written by the Scrum expert and advocate Ken Schwaber. This book is the essential source for understanding scrum and all of it’s components, ceremonies, rules, etc. It will give you situational examples as well as the roles that are needed in order for scrum to work efficiently and effectively.


agile project management with scrum
BUYNOW

8 – The Software Project Manager’s Bridge to Agility
Authors: Michele Sliger, Stacia Broderick

Review: Written by project management experts Michele Sliger and Stacia Broderick. This book is an essential guide for Project Managers looking to transition from traditional project management to agile project management. It gives a very well explained concept of how agile is actually project management compliant by the PMI standards.


The Software Project Manager's Bridge to Agility
BUYNOW

9 – Agile Retrospectives: Making Good Teams Great
Authors: Esther Derby, Diana Larsen, Ken Schwaber

Review: Written by agile experts Esther Derby, Diana Larsen, and Ken Schwaber. This book gives an activities based approach to collecting and examining the details you will need for your agile retrospectives. It gives a very good all round view on how to keep track of those moments that will need to be used in your retrospectives throughout the iterative process.


Agile Retrospectives
BUYNOW

10 – Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition
Author: Lyssa Adkins

Review: Written by agile coaching expert Lyssa Adkins. This is the essential guide for all those in a management or coaching role to an agile project. This book will help you identify when you should or shouldn’t become actively involved in the agile team dynamics. It gives a very well balanced approach to coaching while using agile principles.

Coaching Agile Teams
BUYNOW

10 Signs of Unsound Agile Individuals

Posted on by

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

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

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

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

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

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

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

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

4 – They would rather work alone

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

5 – They prefer low-effective forms of communication

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

6 – They think that agile alone guarantees project success

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

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

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

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

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

9 – They judge unsparingly

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

10 – They have low EI (Emotional Intelligence)

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

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

[Image courtesy of iosphere at FreeDigitalPhotos.net]

How to Define Your Kanban Workflow Management

Posted on by

Whether or not your workflow management tools include a kanban board with a workflow process via an actual (low-tech) office wall or having a (high-tech) virtual agile software board, you want to avoid having too much WIP (work in progress). If there is too much WIP, you may create too much waste or risk in the form of lagging partially completed work, or excessive waiting. Furthermore, excessive WIP will also cause blockages to be obscured and hidden.

Here’s an example of a comprehensive status workflow automation from beginning to end:

New –> Open –> In Progress –> Code Review –> Code Committed –> QA Ready –> QA In Progress –> QA Passed [or] QA Failed –> UAT Ready –> UAT In Progress –> UAT Passed [or] UAT Failed –> Closed/Done

A more simplified (and recommended) view of this workflow process would look like this:

To Do –> In Progress –> Done

how-to-define-your-kanban-workflow-management/In either workflow solution, it is in everyone’s best interest to place WIP limits. Before your sprint would start, you should be able to determine based on the story points and team size what the typical limits should be as per the agile team roles and team members. These can then be calculated and factored to represent the overall WIP limits for your board to prevent too much clutter. However as you can guess, the comprehensive example above or any type similar to it, would be the most difficult one to set limits to, since the stories would be scattered everywhere across multiple statuses.

Like any complex procedure, it is best to break it down into smaller parts. A simplified board should be used as your dashboard view to get a consistently general view of progress.  Once you’ve scaled down your board as much as possible the WIP limits will become easier to manage. A notable mention is the status “Blocked” which can be shown with a more specific indication of which workflow the block occurrence came from, i.e. Blocked in Dev, Blocked in QA, or Blocked in UAT. This will further allow for a quick response to the blockages.

The example given above assumes workflow management processes are happening simultaneously, but it would certainly be more appropriate to create some workflows in later sprints or specific milestone date if you knew, for example, that UAT was coming at a much later time. The key is to keep it simple.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Top 5 Agile Myths and Misconceptions

Posted on by

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

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

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

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

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

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

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

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]

Sharing is Caring – Why Transparency is Necessary in Agile Teams

Posted on by

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

The Agile Team Dynamics Working Toward Transparency

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

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

What Breaks Transparency

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

Here are a few of such causes of fear:

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

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

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

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

How do we get past fears?

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

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

[Image courtesy of Ambro at FreeDigitalPhotos.net]

How to 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