How to use SIPOC for mapping Agile delivery process

How to use SIPOC for mapping Agile delivery process

by | Jul 19, 2020 | Agile, Delivery Leading, Product management, Project management | 0 comments

There are many process mapping tools available and SIPOC is one of them that delivery leaders can use for their Agile initiatives. SIPOC traditionally has been used in Lean Six Sigma process improvement projects.

“But Lean Six Sigma isn’t Agile!”, You may exclaim.

Let’s not get into the debate of what is and what isn’t. As good Agile delivery leaders we want to have more than one tool in our toolbox and this might be one of those tools. For example, finding a right starting point for a new initiative can be hard for many delivery leaders and we could use SIPOC for that purpose. You can also use it early in the project to create alignment among your team and stakeholders.

Another important thing to remember is that we can learn tremendously from other disciplines. If you haven’t yet, then I strongly recommend that you read “Range: How Generalists Triumph in a Specialized World“.  The author, “David Epstein shows that the way to excel is by sampling widely, gaining a breadth of experiences, taking detours, experimenting relentlessly, juggling many interests – in other words, by developing range”.  (Excerpt in italics taken from the book introduction on Amazon.com).

By learning tools and techniques outside from our own craft, and sometimes outside from our profession, we learn more about ourselves.

Table of Contents: 

What is SIPOC?

Why use it?

Who should be involved in the process?

How to create it?

Benefits of using SIPOC

What is SIPOC:

Sipoc is a process mapping and definition tool. The letters stand for: Suppliers, Inputs, Process, Outputs, Customers. These are the heuristics that guide us for defining a process at the commencement of a project or an initiative. You can also use it for process improvement activities (continuous improvement must be an ongoing goal for you).

SIPOC is like a customer journey map because both define a process while keeping the customer in mind. SIPOC compels you to think through the whole journey of a product or a process, beginning from a supplier to the customer. Without thinking in terms of suppliers, their inputs to a process, the steps of your process, the outputs that your customers may get, you might miss important details.

A key difference between SIPOC and Journey mapping is that a journey map focuses entirely on a customer’s experience, while a SIPOC focuses on an end to end process. This may also appear like a drawback of SIPOC that it talks about the customer last.

Another concept that is quite close to SIPOC is Value Stream Mapping (VSM). Since VSM is a Lean concept, it is used more often by Agile teams than other concepts. However, as I previously suggested, there is nothing wrong in having another tool in your toolbox.

Why use it?

Like any other mapping tool, the strength of SIPOC lies in its visualisation and simplicity. If a process is written in a thick, multi-page document, the chances are no one would read that and the creator will not receive any feedback. Since SIPOC can be created on an online tool like Whiteboardfox, or in-person using an A3 page or using sticky notes, it is far easier to get feedback.

Another reason for starting with a SIPOC instead of jumping straight into a process mapping exercise is that it enables teams to think beyond the process. When you use it, you have very little chance of missing on high-level process steps and the scope inclusions and exclusions.

Moreover, SIPOC provides a structured and simple way to convey and brainstorm a process.

Who should be involved in the process?

Ideally, the team members that will support your initiative and work on it should be involved in the process mapping exercise. Any stakeholders that have interest in your initiative should also participate in this process. That is, you should ensure that the process does not miss inputs from key people.

How to create a SIPOC diagram?

SIPOC is an easy to use tool. It is often presented in a tabular or diagrammatic form. Your starting point is to draw five items which are Suppliers, Inputs, Process, Outputs and Customers.

Supplier: Make a list of everyone or everything that might provide an input in your process.

A supplier can be those people or groups that provide inputs into the process. For example, a supplier can be a stakeholder or a sponsor of an initiative. A supplier can also be an upstream system or a process and a customer might be a downstream process or system. Think from provider- receiver or cause-effect point of view.

Process: Begin with a starting point of a process. Your process might depend on the inputs provided by the suppliers. Once you have a starting point, describe the key steps till the end. With having clear starting and end points, it would be easier for you to complete the full chart.

Output: An output is what we produce or deliver as information, service or a product that our customer uses.

Customer: People / groups that receive and use the output of the process. A customer benefits from the process.

Benefits of using SIPOC: 

A SIPOC diagram is easier to create. It allows collaboration between various groups and helps us create a shared-understanding. Since many people provide their inputs, they also feel ownership. Of the initiative.

Some of the other benefits of SIPOC are:

– it provides a high level overview of the process

– it helps us define the stakeholders (suppliers and customers)

– it define and clarifies the scope and boundaries of a process, and most importantly

– it helps a team to understand how their process serve the customer

So, you now have another tool in your toolbox. Let me know if you find a use of this tool.

Additional Reading:

For familiarising youtrself on such topics, Wikipedia is always a good starting point. But don’t stop there. Continue exploring more if you find a topic useful.

https://en.wikipedia.org/wiki/SIPOC

SIPOC definition on ASQ

Using Kudos Cards to Recognise and Motivate Your Colleagues

Using Kudos Cards to Recognise and Motivate Your Colleagues

by | Jul 12, 2020 | Agile, Culture, Management | 0 comments

We’re living in a world where economy has been constantly affected due to one thing after another. There have been natural calamities such as floods, Bush fires, typhoons, earthquakes and as if those things weren’t enough, we are now dealing with a virus that doesn’t seem to stop creating havoc. 

A suffering economy means that people’s livelihoods have been affected. Mostly in an unfavourable way unfortunately. That also means that our motivations have taken a hit too.

Those who are still working might be dealing with anxiety, stress and panic and they may not even know about it. In such circumstances where people are dealing with heightened emotions, keeping their motivation high becomes difficult and even more important. 

What can we do so that we can help our colleagues, peers and friends motivated?

The Factory School of Thinking for Reward and Recognition:

Traditionally, organisations have been using monetary awards for rewarding or recognising employees. The old school thinking has been that if someone has demonstrated good behaviour, or has done some good work, offer them some money and they will be happy. The management also believed that if one person got a reward, that would motivate others as well.

Contrarily, the monetary awards often made a situation worse. That created a rift among employees. It seldom happens that everyone celebrates one person’s success. In some cases, one person’s win is also seen as everyone else’s loss.

We humans have tendencies to laugh at others’ misery. Don’t believe me? Remember the last time you laughed at someone who slipped and fell. That might even be in a TV show. Schadenfreude is a real thing unfortunately.

What Should Companies Do? 

Motivating employees and keeping their morals high is not an employers job only. Since we are all in these troubled times together, each one of us has to do our bit to improve our work practices, keep our work enjoyable and keep our colleagues in high spirits. 

How do we do that?

There is a simple and effective way of doing that and that is called Kudos cards! These are also known as Hero cards but let’s stick to ‘Kudos’.

Paraphrasing Management 3.0, Kudos cards are a written and public expression of appreciation and recognition of a team member for something that has contributed to the team.

As an employer, what you can do is either buy a deck of cards for your teams or provide them with a virtual or online version of Kudos cards. That would be a very little expense for a large gain. 

Kudos Cards: An Effective Way to Increase Intrinsic Motivation:

Jurgen Appelo is the creator of Management 3.0 methodology, which is a way of modern management thinking. This is what Management3.0 says about Kudos cards, 

“Kudo Cards are simple cards that play the role of a physical token of appreciation. The cards can be placed in a box, and every now and then the Kudo Box is emptied and the workers celebrate those who had received a card.“

Kudos cards are simple notes that focus on one and only one attribute. For example, they may show “Well Done”, “Thank You”, “Great Job”, “Congratulations”, “You’re Awesome” etc. Who wouldn’t love being recognised as a badass by their colleagues?

In their physical form, they look like this:

If you and your colleagues work remotely, consider using an online version of these cards. These cards are available for free download from the Management 3.0 website. There are several other websites that allow you to do it for free or for a small fee, for example Kudoboard (https://www.kudoboard.com/).

If you use Trello, Microsoft teams or Slack, they can also be very effective tools for Kudos.

One of my teams created a separate channel in Slack for Kudos and another one used Microsoft Teams Planner for that purpose. In fact, I found that using Slack was a fantastic idea considering that it was constantly in use. 

You can also create your own card in PowerPoint or other drawing tools. The idea is that since the receiver feels appreciated, it is highly likely that they would prefer keeping the card as a memoir. In one of my teams, we used to stick the physical cards to the wall (please see the photo). However, some people decided to take them home because they were proud of their achievements and wanted to show the cards to their friends and family. Isn’t that nice?

Why use Kudos cards: 

I have been using kudos cards for a while now and what I have experienced is that when team members do recognition of each other, the feeling is much more stronger and the positivity lasts longer. It is completely opposite to what I have observed with management rewarding employees on special occasions.

When team members recognise each other, they feel appreciated. They believe that the recognition is honest because that is based on the work or the deed they have done. It is all fact based. Another good thing about mutual recognition is that they don’t have to wait for a ceremony. There is no need for a quarterly or annual function. Employees take care of their own happiness.

Some observations about when to use Kudos Cards:

First of all a word of caution. Don’t use Kudos cards too much because then they’ll lose effectiveness. Also, you should only give a kudos card to someone who has done something right in terms of contribution and you really want to recognise their effort. These cards are for genuine and honest recognition. Without honestly they are worthless.

What I have experienced is that each team creates their own timeline, space and frequency for recognising each other’s work. 

In one of my teams, they used Scrum events like Sprint Review and retrospectives for recognising their colleagues. Another one decided to use every possible opportunity to use them. It totally depends on the team.

Luis Goncalves has written a post about how Agile teams can use the cards in Retrospectives. Read it here.

What might be useful for a team is add something about Kudos cards or regularly recognising team members in their social contract. If you do not know how to create a social contact or a working agreement, visit this page. Since teams do or should refer to their social contract frequently, that should remind them of using the cards regularly.

In conclusion, I believe that Kudos cards are a very effective way of appreciating your colleagues. These cards help improve team bonding, generate positivity, enhance collaboration and peer to peer relationship. There’s no rule for not using them for recognising your boss or an employee through them, but you’re the best judge for their usage and your context. In difficult times, we have a responsibility to support our colleagues and peers. Why not use Kudos cards for that.

If you have used Kudos cards effectively, let me know by adding a comment. 

How to create a social contract that works

How to create a social contract that works

by | Jul 6, 2020 | Agile, Culture | 0 comments

Good Agile teams are self- organising where all ideas matter, everyone contributes and everyone is heard! 

For becoming a high-performing and self-organised team, a lot depends on how team members work together and how good of a shared understanding they share. In complex Agile working environments, it is not easy to rely only on technical skills and attention should be paid on creating cohesion. This is where social contract comes into picture.

 A social contract (also known as working agreement) allows Agile teams to define and agree on the acceptable and non-negotiable behaviours.

 In this post, we’ll look at following points:

  • What is a social contract or a working agreement?
  • Why do you need a social contract?
  • Who creates the Social contract?
  • How and when to create a Social contract? 

What is a social contract or a working agreement

A social contract is not a legally binding agreement. Instead, it’s a socially binding one. What that means is that each person in a team agrees and adheres to certain behaviours that the team mutually creates. Social contracts are unique to a team because each team has people with different personalities, idiosyncrasies and objectives.

Below is an example of a social contract: 

 You can also add other, more specific topics in your social contract. One of our contracts included these:

  • No open laptops in meetings
  • Meetings are not scheduled between 3-5 PM
  • No mobile phone in meetings or team discussions
  • Update cards daily on the wall (later we edited that to include MS Teams and Jira)

An important point to note is that social contracts should not be created and used as a box ticking exercise. Instead, they should be adhered to and revisited as often as required. If you’re a physically co-located team, place the agreement somewhere where it is visible to everyone. If you’re all working remotely, make it a part of your shared area where it is easily accessible and visible.

Why do you need a social contract

 Long time ago, we had a developer in our team who used to disappear during the mid-day when most of the teams were on lunch break and used to return after nearly an hour and half. Not only that, he used to leave early to pick-up his child from the day care centre. It was a concern for most because there was enough dependency on this developer and his unavailability was affecting others.

What would you do if you were being affected in this team?

Our team decided to use the social contract to remind everyone of their commitments.  In one informal meeting (it’s important to note that such discussions are more effective when not done in a formal setting), while chatting with each other team members asked him about this developer’s long breaks. It turned out that he was utilising his lunch break for visiting a gym and wasn’t aware that others were being impacted by his absence.

Because of a social contract where all were free to respectfully share their views, we were able to avoid what could be a difficult discussion.

What I have experienced is that social contracts help build psychological safety, openness, shared understanding, trust, congruence and a sense of accountability.

Who creates a Social contract?

Many teams have their social contracts created by someone in the management or the human resource (I guess calling it People & Culture is better) teams. Well, that’s not how a team contract should be created.

 For a team to become self-organising in a real sense, it is important that they define their own ways of working and guidelines. When the team creates their own standards, they will own it and will be committed to it. Creating and owning something collectively also helps teams establish better relationships with others.

  

How and when to create a Social contract?

A team should create a social contract when it is forming. However, many teams constantly grow and there may not be a single, common beginning for all team members. In that case, the core team or the group of people who join the team in the beginning should create a social contract. This core team should also ensure that every time a new team member joins them, they are given a walkthrough of this contract by other team members. They should also feel safe in reviewing and contributing to this contract. If that happens, the social contract will work in favour of the team.

 

Tips on how to create a social contract:

  • Get together as a team. If teams are located remotely, ensure people are able to turn their videos on. For such an important discussion, it is vital if team members can see each other.
  • Collectively choose someone who can facilitate the discussion. Social contract discussion can generate debates and having a good facilitator will help everyone stay on track. A facilitator will also help in ensuring that all get a chance to speak up. The facilitator does not have to be a delivery leader, a scrum master or a coach.
  • You may ask each team member to write what they expect from everyone in the team
  • If the team is located remotely, use a tool like Whiteboard Fox or Miro to collect ideas.
  • As a team, decide what common behaviours the team accepts as a minimum. 
  • Agree on what are non-negotiable behaviors.

Social contracts are mutual agreements and they should be enforced by the team. They are not pretty posters that teams use to appear Agile. These agreements are to build trust and to reinforce the feeling that a team is empowered and is in control. They also show that the team does not need to be controlled or commanded by someone in the organisational hierarchy.

It is also worth noting that these agreements do not replace organisational policies. Those policies are the boundaries within which teams function. Instead, working agreements are there to enhance the cultural aspects of an entity.

Do you have a social contract with your team? What is your experience from using it? 

Additional reading: 

If you are curious about the term Social contract and where it came from, a good starting point is Wikipedia. It is quite interesting too.

Although not directly related to Agile delivery, the text on Wikipedia speaks about the social contract theory or model as defined in moral and political philosophy.  One can argue that the statement below indirectly applies to how we behave in teams: 

“Social contract arguments typically posit that individuals have consented, either explicitly or tacitly, to surrender some of their freedoms and submit to the authority (of the ruler, or to the decision of a majority) in exchange for protection of their remaining rights or maintenance of the social order.” 

To learn more about the Social Contract Theory, visit these links:

https://www.iep.utm.edu/soc-cont

https://politicalsciencelessons.com/social-contract-theory-by-thomas-hobbes/

https://www.reference.com/world-view/thomas-hobbes-social-contract-theory-1c0d40a2e08398e2

 

 

Agile team practices that showed us immediate results

Agile team practices that showed us immediate results

by | Jun 16, 2020 | Agile, Coaching, Productivity, Visualisation | 0 comments

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.

Culture:

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

by | May 8, 2020 | Agile, Coaching, Culture, Leadership, Management | 0 comments

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

 

** http://www.slideshare.net/EmielVanEst/did-toyota-fool-the-lean-community-for-decades

What are you scaling? Agility or complexity?

What are you scaling? Agility or complexity?

by | Jul 7, 2019 | Agile | 0 comments

When executives, managers & even team members say that scaling Agile was about scaling the usage of practices (& tools) to more teams and departments, what do they really mean? Or, do they know what they were talking about?

Scaling agility is about increasing efficiency, productivity, honesty in communication and breaking the boundaries for shorter feedback loops. The goal is not to scale up, but to solve business problems and achieving outcomes. By increasing usage of practices over what I said above, we inadvertently scale complexity. This is when scaling up turns into screwing up. Be aware if your scrum of scrums becomes a SoS call.