Category Archives: Agile blog

Team Leadership, 101 – 8 best practices for Building Better Teams

Team Leadership

From developing a vision to staying focused on short- and long-term goals,
from talking about the tough stuff to having fun whenever possible,

these eight team leadership traits help project leaders build high-performance teams.


Which ones do you already do well, and which ones might you work on?

Building a high performance team is a lot of work, especially for the team leader.


But as one manager said, it’s a lot more work to not build a high performance team.


Some team leaders consistently demonstrate the traits necessary to make their teams into high performance teams.

They can be taken out of one team, dropped into another and within 18 months,

they’ll have made the second team into a high performance team.


Whether their old team stays high performance or not will depend upon the leadership traits of the new team leader.

Develop a Vision

More than anything, team leaders of high performance teams are visionary leaders.

They don’t start by looking at where their team is; they start by looking at where they want their team to be. Based on that, they work their way backwards, to figure out how to get there.

A vision is a picture of where you want to get to; not the path to get there. It’s what the team will look like, when it’s arrived. But just having a vision isn’t enough;

the team leader must become infectious with that vision, getting their team to buy into it and make it their own. The vision may start with the leader, but it doesn’t end there.

That vision becomes the team’s vision, not just the leaders.

Simple slogans are the best way to communicate visions — something short that encapsulates the vision and gives the team something to buy into.

One of the best was created by Herb Kelleher, former CEO of Southwest Airlines.

His vision, and the slogan that went with it, became the yardstick by which every decision in his corporation was made.

Everyone from the boardroom to the back room understood that slogan and bought into the vision that it contained.

Kelleher’s slogan was, “We are THE low-fare airline.” You don’t even have to be in the airline business to understand that; all you have to do is read it. New employees could have as much understanding of corporate culture and philosophy as the most experienced manager, just by understanding that simple phrase. It captured the vision which Kelleher had for Southwest Airlines, making it something that everyone could buy into.

While not every vision is shared so eloquently, every leader should strive to do so. The clearer and more simply the vision is stated, the easier it is for team members to buy into it.

Be Genuine

High performance team leaders don’t live in an ivory tower, separated from their loyal subjects. They are part of the team and know when to open up and lower their guard with team members. They aren’t trying to project an image that they’re perfect, but are willing to show their own vulnerabilities, especially if it can help out another team member. This actually helps them gain the respect of their team, much more so than trying to appear perfect.

This requires confidence in yourself and being able to laugh at your own mistakes. People who have to appear perfect often feel that way because they lack self-confidence. Yet, being willing to open up and be vulnerable can do more to make a team come together than standing aloof.

Talk About the Hard Things

Every team has difficulties; the question isn’t whether or not they’ll crop up, but how you deal with them. Team leaders of high-performance teams recognize those difficulties and the problems behind them. They are willing to talk about the tough stuff, even though it’s uncomfortable to do so. Their goal is always to work through the problem, gaining victory for the team.

Some leaders try and avoid conflict. All this does is to make the problem fester, like an infection. That infection will eventually cause the team to become “sick” and dysfunctional. While nobody enjoys the conflict, going through it is necessary.

One of the difficult things that these leaders have to do is to confront non-performing team members. There are many reasons why a team member might not be performing up to expectations, and it’s the leader’s responsibility to find out the reason and do whatever is necessary to fix it. Sometimes that means finding the team member another team where they might fit in better.

A non-performing team member can sabotage the efforts of the entire team if they aren’t dealt with. They may be the type of person who causes division or who has to be in the limelight, or even one who rejects any leadership. Regardless of their problem, if it’s not dealt with, it’s like a plague eating away at the team.

Know How to Listen

Communication is a two-way street. Many leaders speak first, then, if there’s time, they’ll listen. Not so for team leaders of high performance teams. They know how to listen and generally listen to their team members before speaking. Remember, leadership in a high performance team is a collaborative effort. These leaders don’t see themselves as “the boss” who everyone is there to serve. They see themselves as facilitators, allowing their team to take its own direction.

An important part of this is listening. Everyone wants the opportunity to be heard, even the lowest person on the totem pole. When these team leaders listen, they make the team members feel more important, that their contributions are critical to the team.

Sometimes it’s not enough just to listen; the team leader has to get others to listen as well. A positive environment can’t happen if team members are being negative towards one another. It’s the team leader’s place to put an end to this as soon as it starts. Maybe the idea that a junior team member is putting forth won’t work and won’t be acted upon, but they should be encouraged to express it nevertheless.

Ask Good Questions

Questions are a valuable tool. The right sort of questions can lead somebody to look in directions they never intended, to find the answers they so desperately need. Besides using questions to direct people, these team leaders use questions to keep themselves abreast of what is happening in their team.

It has been said that we have been given two ears and only one mouth, so we should listen twice as much as we talk. Listening is an art form, and asking questions is a tool to active listening. Yet, asking a question, without listening to the answer, is one of the fastest ways of showing a team that you don’t care about them. Good questions have to be followed up by attentive listening.

Are Dependable

Good leaders have to be dependable. If the team is going to learn to depend upon one another, it has to start with learning that they can depend upon their leader. That means that the leader must carry through on whatever they say. If it proves impossible to complete what they have said, they must explain why, or they will lose their credibility in the eyes of their team.

People will do much more for a leader that they trust. In the military, one of the highest compliments an officer can receive, especially from an experienced sergeant, is “I’d be willing to follow you into battle.” Whether we see it or not, our team’s activities are a form of battle. We need our team members willing to follow us into that battle and win. That means that they have to trust us, which can only happen when we prove ourselves dependable.

Being dependable also means speaking clearly to team members. Most people can see right through a lot of the lies and misinformation that management passes out. While they may not be able to see what the truth is, they’ll know the false when they see it. Being honest with the team is another form of dependability. It shows them that they can trust what you say and you’ll stand behind it.

Know How to Have a Good Time

Everyone likes to have a good time. That’s a necessary part of team building. Leading a high performance team means leading them in having a good time together as well. However, they never do so at the expense of another person, especially another team member. Sarcasm and other cutting comments have no place in team fun, because they always hurt somebody.

Having fun doesn’t have to come at the expense of the team’s goals. Many work activities can be made fun, if we want to do so. A lot of that has to do with how we approach those activities. If we approach them as something that we’re going to do together as a team, we set the tone for making them fun.

Are Goal Oriented

Goals are the compass that directs the team. Regardless of what team activities are being undertaken, a high performance team leader will always keep them goal oriented. It may be the team’s ultimate goal or it may be an intermediate goal that will help the team reach that ultimate goal. It’s still a goal and the team leader will keep it in focus. They’ll also ensure that their team can keep it in focus as well.

This doesn’t mean that the leader has tunnel vision. Team-building activities may seem to some like a waste of time. However, those team-building activities are necessary to forge the team into a high performance team. Therefore, including them in the team’s work schedule is helping the team reach its goals.

The above is an excerpt from Michael’s all-time bestseller

Leadership: Building Highly Effective Teams How to Transform Teams into Exceptionally Cohesive Professional Networks – a practical guide

Find also on Audible



Agile? Three more practical practices – test if you’re Agile.

In the previous post: Are you Agile? In business? In Life? Three practical practices

Based on our practical consulting and coaching experience we discussed three of the six criteria to verify whether an approach is Agile:


Adaptation, Incremental Iteration and Time boxing.


In this post we describe the remaining three: Assuming an empirical approach to problems and challenges, Focusing on the important rather than on the urgent, and being Collaborative customer driven.

Assuming an empirical approach to problems and challenges – an empirical approach suggests that solving problems and overcoming challenges is based on observation and experimentation. Many times it involves a creative investigation of solutions.

An empirical approach can be contrasted with the theoretical approach which many organizations employ.


One of my clients in research and development of aeronautical components spent too much time theorizing possible solutions to complex engineering challenges; lagging behind the competition.

They collected data, analyzed and projected in order to apply it according to a theoretical model without practical results.


By implementing an empirical approach, as part of their Agile transition, they proactively changed structural elements and followed through according to the results, similar to software spiking, thus receiving faster feedback, reducing risks, and progressing faster.

Agile individuals and organizations prefer to experiment and observe rather than theorize.


Acting based on a given set of data, observing the results and tweaking/updating the approach to yield better results.


This is quite similar to the Deming Plan-Do-Check-Act cycle which is the basis of the Agile reflection.


In this sense, being empirical, assuming an empirical approach to problems and challenges is a bit like being a Satisfier rather than an optimizer.

Families and individuals can also experiment with being empirical, by committing to small changes, observing the results and changing their environment in the process.


Rather than preparing a thorough plan to change the dietary intake, practically altering small elements and observing the impacts.

Much of my Gestalt therapeutic work is based on the empirical approach of small experimental changes – the personal results are always impressive.


Retrospect – are the meetings you lead, involve an innovative empirical approach to learning? Or are you wasting time theorizing and procrastinating without moving to action?


Focusing on the important rather than on the urgent – this well-known technique which is at the epicenter of Time management training, is crucial to enabling Agility for individuals and organizations.


Jonathan Mead author of the blog discusses his 5 Ways to Stay Focused on the Important

  • Set 3 Most Important Tasks (MITs) for the day
  • Focus on providing value
  • Think long-term
  • First things first
  • Have a clear vision

The concept of Urgent and Important in time management, reminds me of the Parkinson’s law of triviality. According to Wikipedia:

Parkinson’s law of triviality, also known as bike-shedding, bike-shed effect, or the bicycle-shed example, is C. Northcote Parkinson’s 1957 argument that organizations give disproportionate weight to trivial issues.

Parkinson observed and illustrated that a committee whose job is to approve plans for a nuclear power plant
spent the majority of its time with pointless discussions on relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed,
while neglecting the less-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticize constructively.


Agility in organizations is more than just focusing on the Urgent and Important; it is also knowing what is important, what delivers value, what is crucial to the client and focusing the efforts on the important items.


Retrospect do you regularly update your weekly important and urgent lists?


Collaborative customer driven – we kept this criterion to the end, and yet it is by no means of
lesser importance, on the contrary.
Agile approaches are collaborative development efforts, focusing on the customer.


The ongoing, mutual impacting and trustful exchange with the customer is crucial in achieving Agility.

Collaborative customer driven is actually a result of the first five criteria:

  • Adaptation allows us to change the process according to the market and the customers;
  • Incremental iteration enables verification and delivery of small elements – thus the
    commitment is limited in scope and the frequent feedback enables a change of course when necessary;
  • Time boxing grants predictability while limiting the allocated time and budget/resources to a
    certain effort – often increasing the visibility towards the customer;
  • Empirical approach is cornerstone in moving forward and providing
    innovative, breakthrough solution, many times involving the customer;
  • Focusing on the important rather than the urgent, demands an understanding of what is
    important, what delivers value and what is crucial to the customer.

Agile approaches instill a collaborative environment, inviting the client to participate in the process, while aligning the process according to the customer.


The above practical tests together with the three described in the previous post, validate if an individual and an organization is Agile.

Can you rank your organization according to the six criteria?

Meanwhile I invite you to read: Agile Decisions – Agile Decisions – Driving Effective Agile Decisions in Business published this June, which discusses the relationship between local Agile decisions and top down command and control decision processes.

The Agile PMO

Key message: A project management office contributes value to its organization by helping executives make informed, portfolio-based decisions regarding project prioritization and resource allocation. This article displays how a PMO can accomplish this mission more effectively by delivering value incrementally, focusing only on what is necessary at the appropriate time.

Download article – The Agile PMO – ProjectsAtWork

Tom Jenkins, the newly appointed PMO manager convened his team. Xavier, Paula and Xing were eager to start work. Tom explained that the PMO rollout is a change process. He gave his team assignments around stakeholder analysis, mapping of communication requirements, and creation of the PMO newsletter. While the team was somewhat puzzled with these activities they moved to fulfill them. Working with the stakeholders, the team captured many complaints pertaining to the current way of work and gathered numerous requests for improvements. Eagerly awaiting their next meeting, which was held virtually through a videoconference, they prepared a list of proposed improvements. Xavier proposed to commence work on the work breakdown structure and the software development lifecycle. Paula suggested to update the risk register template and to implement a new tool for project scheduling. Xing reported that the stakeholders were keen on having a team collaboration tool and added that they are many resource conflicts which were not managed at present.
Tom listened carefully to his PMO team and empathized with their concerns. He then patiently detailed his vision of the PMO. While this was not the first time he discussed the vision, it was important that the team revisit the vision in light of their findings. He also instructed the team to communicate the vision continuously to the stakeholders during meetings. He further emphasized the importance of communicating through a newsletter to the global community. He moved to investigate with the team, which stakeholders were appearing to be powerful, interested and supportive to the cause of the PMO, and which were appearing to be opposing and would probably produce obstacles to the PMO implementation. He also offered his perspective around which areas may enable quick wins.
He then engaged the team in a discussion about value creation and how the PMO might provide value to the project and product community. He queried the team regarding the current status of the portfolio resource pool. It was evident from the team response that there was a resource pool in existence which was loosely managed, not centrally controlled, and not based on resource planned and actual efforts. Actually, in order to manage the resources on a global basis a new tool had to be implemented and more than 8000 resources had to be updated into the global tool. That was dire news indeed.
It seemed that in order to create value, the newly formed PMO had to immediately invest a huge sum in the procurement and implementation of a new software. Additionally, a new SDLC methodology had to be generated, updated processes had to be written and dozens of templates and work instructions developed.
It seemed a monumental undertaking and the team was at a loss regarding where to begin. They felt that it would be three years before they would start producing value. One of them even suggested hiring a management consulting firm and recruit five additional analysts to help with this huge undertaking. Once more Tom provided support to his team members, permitting them to air out their concerns. Then he explained the concept of the Agile PMO.
100 Days of Grace
He said that they did not have three years to create value; at most they had 100 days of grace before they were expected to produce some initial results. Xavier responded by offering to produce a new version of the risk register which may be not exactly what everyone needed but might make some stakeholders happy and buy the PMO some more precious time.
Tom gently rejected his offer, pointing out that a new risk register while useful, is not what an Agile PMO is about. The new risk register might add confusion and not support value creation and thus would be a waste of effort and time. This led to an extended period of silence and Tom suggested that the team would take a few days to contemplate on how to proceed.
Three days later the team reconvened, Paula proposed an idea. She said that resource conflicts were abundant and that the most value-added activity that the PMO could perform, was to manage resources on a global scale. Tom commented that it was a good idea. Xing questioned the logic of this idea saying, that they are too many resources to manage. Xavier interjected and added that the tool that was in place was not able to support such a task. Paula said that they don’t need to manage all resources, and maybe in an Agile PMO it was enough that they manage only what was needed to enable value creation. The other team members then listened attentively to her idea.
She explained that at this time they do not have a complete list of all projects executed globally and that should be their next task. Once they have such a list they would be able to assess project contribution from a portfolio perspective. Then they would be able to mediate between the different projects and assist management with making educated decisions pertaining to project prioritization based on the full list of projects in the global organization. Tom said that that was a good step in the right direction of being effective.
Eagerly, the team discussed how to carry out mapping of the projects. They defined a template to update the project list into and scheduled a meeting for the following week to review their results. Tom added that it is probably a good idea to present their findings in the newsletter and to continue stakeholders’ assessments regarding support or opposition to the PMO activities.
During the team meeting the week after, it was evident that many pet projects existed, which were using resources without providing benefits to the portfolio. The team mapped about 35% of projects that were redundant and probably unimportant to the portfolio of the company.
Tom said that this was a good example for an Agile PMO. Instead of discussing processes, tools and templates they were engaged in how to make the project and product community more effective. Xing then offered an idea; he said that he had noticed many resource conflicts that were plaguing the projects in his region. He was convinced that these conflicts were occurring between important projects and it was very important to map all the resources allocated to these projects to resolve the conflicts. Resolving the conflicts would enable streamlining important projects, contributing to the portfolio. Xavier said that mapping and allocating all the resources in the region would be impossible as there are more than 800 resources in that specific region, and most of them do not report to timesheets on a regular basis. He added that in any case, the tool in place does not support these reporting requirements. Xing answered that he had given much thought and suggested that initially they map only the critical resources.
The team then deliberated what constitutes a critical resource. Tom offered his perspective and recommended they read an all-time bestseller on the subject of mapping of critical resources by the famous author and physicist Eli Goldratt: “Critical Chain Project Management.” He said that true to the concept of the Agile PMO, they will identify critical resources. He estimated that only 3 to 5% of the total number of resources would prove to be critical. By following this line of reasoning, the team would quickly be able to allocate critical resources to prioritized projects enabling streamlining of the value creating projects from the portfolio perspective.
One month later the PMO team was able to provide an almost complete list of projects in the global organization, along with the list of critical resources. These were the critical resources that impacted project completion. By closely managing loading of these resources, the PMO was able to provide and assist project managers and management with timely-based decisions about resource allocations. The PMO also suggested on terminating none value added projects and transferring employees working on these projects to other projects which were creating value from the portfolio perspective. Three months after inception of the PMO, the impact was already tangible:
1. More stakeholders were moving from neutral attitude to high support of the PMO activities;
2. The low hanging fruit of critical resource mapping provided quick wins which enabled more rigorous undertakings to complement the initial activities.
3. The newsletter was instrumental for conveying the message of value creation from the portfolio perspective;
From Push to Pull
With the support of Paula, Xavier and Xing, the vision set forth by Tom became a reality 20 months after PMO inception. Needless to say that within this time the PMO transformed into a strategic tool for portfolio decisions about future projects. The concept of the Agile PMO translated into a PULL mechanism of projects, whereby projects are selected based on resource pool status. This was opposed to the previous approach of a PUSH mechanism whereby all incoming projects were selected, which resulted in the clogging of the resource pool and thus hindering the streamlining effect and reducing the throughput of projects.
Naturally, with time a unified software development lifecycle was constructed along with relevant processes, templates, and then a new software tool for integrating information globally. The software tool was a natural evolution to the development effort of the PMO. The team understood that using a tool to create change is futile, and rather the tool should be implemented after a considerable amount of the change has been in place. The tool as such becomes a method to encapsulate the change into corporate culture.
In conclusion, the Agile PMO delivers what is needed at the time when it is required. The Agile PMO focuses on the most important value creating activities while keeping sight of the overall objective. This is in contrast to the development of all at once, which tends to be the initial expectation that is expressed by stakeholders. The PMO is not about tools, processes, or a methodology, rather it is about creating value.
This article is adapted from chapter nine of the author’s new e-guide “The Agile PMO.” On Amazon :

Interfacing between Linear Waterfall and Agile Approaches

This article depicts the best practice approach for integrating Agile approaches and specifically Scrum development with traditional overarching linear approaches, specifically waterfall methodology. The agile PMO, properly defined, can be positioned to secure Agile-Scrum benefits while maintaining the necessary overarching control.

Download article – The agile PMO Scrum – Nordic Zone

The challenge
Over the last two decades, various Agile approaches have been introduced and practiced. Of these, in last 5 to 7 years, Scrum has gained the most popularity resulting from a combination of simplicity, ease of use, and effective public relations. Scrum success in software development organizations has been a powerful driver for roll outs across products, industries and businesses. As described, this was exacerbated by a focused marketing effort from Scrum evangelists. Unfortunately, most of these organizations were not structured in a way that supports the Agile-Scrum approach and methods. Even more so, scrum in its raw and pure form is not suitable for the majority of organizations.
The first wave of failed Agile-Scrum implementations brought about an even stricter admonition, based on an unwavering belief from Scrum zealots. The main assertion has been that failed implementations are a result of partial embracing of the true scrum spirit and the full benefits of the approach can only be attained if the entire organization is reengineered. This fanatical attitude left many project teams across organizations big and small, struggling with their already idealistic implementations. Some have been figuring out on their own, how to combine the contemporary and traditional worlds. Other teams have completely abandoned the Agile-Scrum concepts reverting back to the traditional linear waterfall approach and method. Yet other teams, ridden with guilt, manage Scrum by name only, and hiss vehemently at any project management proponent who is unfortunate enough to advise on re-embracing Agile in a more cognizant approach.
The concepts which are presented and embodied in Agile-Scrum are too good to be ignored; however implementing it outside pure software development requires adaptation.
Complex scenarios for Agile
The main hurdle in achieving the benefits of Agile- Scrum outside software development is integrating it with existing control mechanisms. These control mechanisms are stipulated due to various organizational prerequisites and are normally actualized by using the Linear Waterfall approach and methodology. Four of these typical organizational prerequisites are depicted below:
• Big global corporates – in these hierarchical matrix organizations, top down portfolio control is the rule of the day. The free spirited agile approach has a tough time adjusting to the rigorous controls. Specifically the inherent Agile plan-free concepts, make Agile-Scrum difficult for the organization to swallow.
• Highly regulated industries – some industries are required by compliance and governance bodies to have a strict binding control mechanism. These can be for example medical equipment, aircraft, and pharmaceuticals research and product development business units. While individual teams might operate Agile-Scrum, the development process must follow a rigid Linear Waterfall approach method for traceability and governance.
• Complex predefined products – some integrated products which include both hardware, software, imbedded and more are developed as a contract with an end customer under a predefined set of requirements. In these cases the degree of requirement flexibility is small, though larger than what is anticipated initially. The concept of a fully flexible backlog of Agile-Scrum suffers considerably in these cases.
• Generic IT departments – much of the daily and weekly activities in maintenance driven IT departments is ad hoc. Changes to the daily schedules are numerous and immediate. Constant interferences in the teams work are the norm. The concept of time boxing and no interference is difficult to maintain in these situations.
Naturally – many times the four discrete categories detailed above, actually mix; so it is common to find a complex product in a global big corporate which is required to comply with firm regulation.
Based on practical experience, the recommended method to tackle these scenarios and others is by empowering the Agile PMO to act as an enabler, driver and translator between the emerging Agile-Scrum teams and the Linear Waterfall elements.
Refer to the table below for specific guidelines


Important best practices to remember that go hand in hand with the Agile PMO:
• Implementing Agile-Scrum as a restricting admonition is exploiting the adaptive nature of Agile
• There is no one right way – no one size fits them all;
• There is no silver bullet – you can create what works for you;
• Being agile and adaptive also allows being flexible with how one uses the methods, process and Methodology;
• Time boxing is great as long as you are flexible to change the durations of the time box if necessary;
• Sometimes the client isn’t directly available, in these cases marketing and product management are a proper alternate;
• Arbitrary rules don’t complete projects, people do! Empower your team and yourself to choose the appropriate mix of approaches that enable product delivery.
Summarizing – In my book about the Agile PMO I describe how PMOs can succeed only if they create and enhance value through smart portfolio selection (more about that in a future white paper). With the emerging of Agile approaches and specifically Scrum methods new opportunities have become apparent. Integrating them into an existing control structure – typically presented by a waterfall lifecycle – can be frustrating. We have defined a new key player – the Agile PMO which can be positioned to create a transformation / translation layer between the approached and methods, contributing to higher success levels of these integrations.

Michael Nir, President, Sapir Consulting. He can be reached at
The above whitepaper is excerpted from: The Agile PMO In print: Join Michael for a 2 day workshop in New York: The odd couple – Marrying Agile and Waterfall. Learn Breakthrough tools and techniques for integrating Agile in a Waterfall environment; immediately increase value from the AGILE PMO in hybrid setting and Increase Agile / Scrum hybrid implementation success.