Agile team practices that showed us immediate results

Agile team practices that showed us immediate results

There are times when culture and the practices that a team follows (or does not follow) start affecting their delivery work, primarily in Agile teams. Non-essential meetings, unplanned or unwanted catch-ups, feeling lack of safety that forces people to keep record of things such as emails, are often part of a bigger problem.

As a delivery professional (Lead, manager, Scrum Master and in some cases even product owners), your responsibility is to ensure that your teams delivers the valuable outcomes, at frequent intervals and with a sustainable pace. This responsibility also includes protecting them from non-productive tasks and mentoring them for de-prioritising non-value adding tasks.

Unfortunately, sometimes teams do not even realise that some of their practices were slowing them down. This often happens because of a rigid mindset that is ingrained in their organisations and the cultures. And as you might already know, it takes time to change behaviours and attitudes that become norms.

The good news is that you can possibly change that mindset.

How do you do that?

The answer lies in the teams. Teams are built of people, and people prefer to stick with social rules. In fact, it is often hard for people to oppose or show resistance to norms of a group that they are part of. As an Agile delivery leader, it is in your and the organisation’s interest that you encourage your teams to develop a social contract or a working agreement. These contracts define how the team members in a team prefer to work together and what they find as acceptable behaviours. Since everyone in a team contributes and agrees to the principles of a social contract, it is also easier to improve practices that affect them most.

Just to be clear, these social contracts are not legally binding agreements. They are there to enforce the values and principles that people in a team believe in and agree to adhere to. 

I was working with this team of nearly fifty people as a delivery manager. The team was consisting of four product streams and there were interdependencies. We were facing some common challenges regarding the day to day functioning of the team. Through the retrospectives, I came to know that there were few common patterns across those streams where the teams were feeling the pinch.

I was able to break those patterns in four themes: 

Productivity (and process improvement)

Culture (behaviours & attitudes)

Development & growth 

Clarity of Mission

All of these themes can be summarised in some of the key challenges:

– Too many meetings. Many of which unplanned and go on for too long

– Lack of agenda and expected outcomes in meeting requests

– Lack of a medium for team members to appreciate their colleagues across the program

– A need for a common platform for the whole team to come together and share ideas

– Finding time for training or capability uplift

A need to know each other better which was a challenge due to the size of the group

– Clarity of roles at program level


Here’s how we solved the problems:

Productivity + process improvement:

There were too many meetings and this large number of meetings was not only affecting productivity, it was also impacting delivery schedule. Since meetings were reducing productivity, team members were also getting visibly annoyed. 

This is what the team decided to do:  

  • No one within the team was allowed to schedule meetings after 3 PM. What that meant was that people get unrestricted productivity time after 3PM.
  • Everyone in the team agreed that each meeting request will have a clear agenda and if possible, the outcome they were looking for. 
  • We also attempted to limit the meeting times. That is, any 30 minutes were planned for 25 minutes and any 1 hour ones were planned for 45 minutes.
  • We also asked people to come prepared so that their messages were concise and crisp.
  • We emphasised on face to face conversations whether people were onsite or working remotely.  

We kept an eye on these practices for adherence and ensured that everyone, specifically the senior team members behave like role models.


The program director and I were closely aligned on the values that everyone in the team adheres to. Having a shared understanding at the management layer certainly ensures how each member of the team will behave.

  • We encourage team members to be completely open and honest in retrospectives and otherwise too. We also made sure that our own behaviour reflects what we were advocating for.
  • I attended and at times facilitated team retrospectives. What was motivating for me was that often team members approached me after the retrospectives showing their appreciation for making them feel safe in those sessions. Team retrospectives were purely for the team members and neither product owners nor anyone from the program team were allowed to attend unless required.
  • We made sure that the program management team accepts the improvement areas and takes actions. We circulate those actions to the team members so that they can see the congruency.
  • We also ensured that we provided regular updates on the status of the action items.    
  • To encourage peer to peer appreciation, we introduced “Kudos cards” in the program. When we introduced the cards, we also explained why there was more value in appreciating those who deserve and why a reward system from management does not work. 
  • Monthly retrospectives: Due to the interdependence within the streams, it seemed vital that the whole team has a common retrospective. Team retros also reflected that need. Hence, we decided to schedule a monthly retros for the whole team. In these sessions everyone in the team came together to share ideas openly and respectfully.

Development & growth:

Many project or product teams do not have additional budgets for training for their team members. Depending on the structure of the organisations, team members might belong to different specialist groups that are responsible for their professional development. Sometimes People and Culture (a.k.a HR) teams are responsible for arranging training. Dealing with some of these processes can be cumbersome due to bureaucracy. So what do you do then? Well, see how might you get your team some training and mentoring. We found the answer in some unconventional ways. We agreed that you don’t always have to separate training from ‘business as usual’. Therefore:

  • We build small pockets of training time in each team event. We had a quarterly team events calendar and we specified training time in the calendar. For example, to enhance team collaboration, we added a ‘personal mapping’ exercise in a monthly showcase. Easy! 
  • We placed a flipchart in the project room with suggestions as well as space for other ideas. Team members could either opt for an existing training sessions or could suggest a new one. There was enough autonomy to add anything and we did see some funny suggestions too.
  • We made sure that there were options for lunch-time sessions, brown-bags, separate training and even ad-hoc sessions. Once we organised a session on user stories by extending our stand up to an extra 30 minutes. What you might find hilarious that we expected 5 attendees, but nearly 25 people showed up. 

 Clarity on roles: 

Sometimes within large teams, where you are adding new members regularly, it is difficult for team members and leads to explain various roles (just to be clear, I’m not talking about titles here). In our case, we had data architects, data engineers, CX designers, UX designers, delopers, testers, business analysts, solution designers, legal counsels, procurement people, scrum masters, product managers, domain architects and others. With so many roles, not only explaining them can be hard, but also keeping them clear to avoid overlaps. You don’t want people unknowingly stepping on each others’ toes. Neither you want any frictions among team members, no matter how psychologically safe you believe your team is. We’re all humans after all!       

  • We created a team structure chart that clearly showed who was working on what. We also made sure that the chart shows which stream people belonged to. We circulated this chart to everyone in the team and also added it to our induction pack that we shared with all new team members. 
  • Although I am not a big fan of RACI matrix (responsible, accountable, consulted, and informed), it deemed necessary to us to create one. Of course we consulted our team about what they thought about it.
    Why I’m not a big fan of RACI matrix? Because these matrix define linear responsibilities. That is, one person =  one specific role. If you are a self organising team, you may have team members playing different roles. However, having this chart helped us bring more clarity about roles and it also reduced overlapping and multiple channels of similar conversations. Additionally, team was clear that their self-organisation wasn’t at risk.
  • Skill matrix: Now this is something that was interesting.  I had used skill matrix before to create cohesive, well designed, self supported teams. What a skill matrix does is to show the availability, lack of and level of expertise for a particular skill. For example, you may have someone very experienced in C++ and you may also have someone willing to learn it. As a lead, you can take actions to balance the skill shortage. For me, this experiment failed as no one ever willingly added their skills. I also trouble validating why that happened. Anyways, this was added to our ‘Failure log’.

As you might have noticed, we solved many of our problems by bringing people together. Creating common understanding was our first step in ironing out some of the challenges we faced. We also did a number of experiments and not all of them were successful. However, keep running short experiments, validating them through feedback loops and not losing focus from your primary goal can do wonders for your team. 

Did you do something similar in your organisation? How did that go? Let me know in comments.  

It’s not Agile that fails organisations. It’s the organisations that fail at agility

It’s not Agile that fails organisations. It’s the organisations that fail at agility

Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. Those who understand, have been observing some interesting posts and discussions going on social media that claim that Agile has failed in their organisation.
If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation. That’s be similar to any other tool that an organisation might use.  Sometimes tools work, sometimes they don’t! Understood! A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just too be clear, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
They don’t know enough about Agile and they tried to “do Agile” rather than “be Agile”.
They thought that they knew about Agile and implemented it the way we knew it. What they did didn’t work. (Rajesh’s note: you don’t implement Agile in the same way you don’t implement truth.
They thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. Despite those they couldn’t deliver anything.In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. Many Scrum Masters never looked at The Scrum Guide. Some didn’t even know it even existed. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to  understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.

So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.


* The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully



Why improving culture can bring dramatic results

Why improving culture can bring dramatic results


It is not surprising that at many organisations, mainly in difficult cultures, management teams increase their focus on individuals and teams when things do not work out. They believe that to resolve any issues or to improve a situation, they need to fix people. While in some cases people related issues might need to be resolved; in many more cases leaders should focus on  improving the systemic issues and the culture of the workplace.

 As a delivery professional, and specifically as an Agile delivery professional, you will face situations where things will not be working out for your teams. There can be many reasons behind those issues, but pay special attention to systemic and culture issues. This post helps you decide whether to be a part of the problem or be the wise person who offers solutions.

 Have a look at this famous quote by Alexander Den Heijer*

 “When a flower doesn’t bloom, you fix the environment in which it grows, not the flower.” 

 What this quote symbolizes is what happens at many workplaces. We see that when a problem appears, the management teams get so involved in the lower level details that it becomes harder for them to see the forest for the trees. In other words, they can’t see the bigger picture. This results in either applying short term fixes or fixing the wrong problems.

 It is true to an extent that many managers find it rather simple to find faults in the teams. Local fixes are easier to apply and they can be shown as quick wins. These quick, local fixes are the low hanging fruits and they are quite attractive because they make managers look good in front of their peers and superiors. It’s amusing how culture of a workplace can affects people’s behaviours.

 It is hard to identify and detect systemic issues. When managers have a narrow view of things, when they are not trained in looking at the bigger picture and think critically, they tend to ignore the signs that the system might be showing them. The issues might be with systems, suppliers, other managers, expectations, equipment, skills or any other things.

Challenges for organisations and delivery folks:

 The challenges that organisations and teams face in solving long term problems are:

 – attractiveness of applying the quick fixes
– incompetence of managers in identifying the right problems, and
– ambiguous nature of systemic issues

Below is an example from my personal experience how management ignores systemic issues and focuses on low level details.

I was once invited to a financial institute to do an assessment of how the Scrum Masters were performing there. The person who commissioned the work told me that the company wanted their teams to improve. Through this assessment, they wanted to see which areas needed further support or training. But, being a sceptic, I was curious to know whether the management was genuinely interested in helping their teams improve or this assessment was a ‘performance review’ in disguise. I didn’t know whether this activity was also going to be used as a ‘right sizing’ tool.

 My assessment process included interviewing various people to get a holistic sense of the working environment. After meeting the scrum masters, program managers, product owners, peers and colleagues, I noted that there were many improvement areas. One of them was additional training for scrum masters, but there were many others which were more work-environment related. What was interesting was that these folks had no control over the issues affecting their work. Most of the problems that were slowing the teams down and impacting product delivery had nothing to do with these scrum masters. Almost everything was an organisational issue. 

When I sent my report to the person who commissioned the work, she completely ignored the recommendations related to the organisational issues and decided to action only what was written about the team members. 

As expected, nothing actually changed for them.


What should leaders focus on?

 Local sub-optimisations can only produce sub-standard outcomes. If you are an executive or a delivery manager, don’t spend much energy on improving efficiency and productivity of individuals (or individual teams). Those things have limitations. Although you do need to solve the immediate issues. Once that is done, Instead, try to understand the dynamics of your systems. If you face a challenge, pay attention to how your overall system is behaving. 

 Can you pick different sentiments in people’s attitude? Do you see that vocal team members have stopped talking? Are teams reluctant in experimenting? Have the number of sick days increased? Have people stopped challenging you or offering suggestions? Has productivity dropped? Is the work produced by teams appear to be of lower quality than it was before? Do you notice a lack of collaboration and cohesion among all levels of people and teams? Have people started keeping record of interactions ‘just in case’ if they had to ‘prove’ something? Has the learning stopped?  

 The list of questions can be very long. All of these questions are the symptoms of larger problems.

 It takes time and effort to understand the patterns and behaviour of a system, but the results, impacts and effects are often better & long lasting.

 How to identify and action systemic issues:

 As a delivery professional, it is imperative for you to learn and experience practices and techniques for systemic issues. Initiatives, projects, assignments and products can vary in size and complexity. You will have to choose the right tool for the right context. I have provided some suggestions below. 

 Systems mapping: Most initiatives have dependencies and interdependencies on a variety of things. These include people, processes, vendor suppliers, equipment, government compliance and regulations, technology, market forces etc. 

 It is a good idea to create a systems map to understand the breadth of your solution. Specifically for large initiatives with multiple touch points, creating a systems map is vital. Once a basic map is ready, other team members can add details that you might have forgotten. Systems maps help leaders see the forest and not just the trees.

 Group mind mapping: You can start your project with a mind mapping exercise with the core members of your team. A mind map not only helps you develop your ideas, it also helps you reveal the potential outcomes or problems. 

 Brainstorming, decision making and problem solving techniques: I have used techniques such as Lotus Blossom for decision making and problem solving. Lotus blossom is a structured way to explore areas which are high stake and require deeper thinking.

 Collaboration techniques: To improve the culture of your organisations, you should apply team collaboration techniques that improve coordination and psychological safety. Once your team members feel safe to speak out and share ideas, you will notice the substantial benefits for your projects.

 You might already know many of the suggestions I have provided in this article. My job was only to give you a nudge and hope I have done that through this article. What has been your experience at applying practices that have helped you improve the culture of your team or the workplace? Please share your ideas in the comments below. 

* Alexander Den Heijer is a well known motivational speaker and the author of Nothing you don’t already know: Remarkable reminders about meaning, purpose, and self-realization