Category Archives: Kanban

The only way to “Empower”​ someone

Posted on by

Time and again we hear professionals talk about empowering a being and how it’s the right way to go. How empowering a gender, race, team member or an organisation helps in improving accountability, ownership and peaceful collaboration. How this makes a robust community of respective subject matter to cohabit with shared goals.

Love the idea, it’s marvelous to see many people are embracing these great ideas. With that in mind, I asked handful of them –

How do you empower someone or a group?

 

Majority of the replies had a short pause, usually with a raised eyebrow, followed by a somewhat vague response like “By giving them chance to see the big picture, allowing them to contribute to the greater cause, authorising increased accountability/ownership and removing anything that blocks them”.

Seriously? Isn’t that what we should be doing anyway?

Technically anyone who is claiming to “Empower” someone is not really doing anything productive. Rather they are stopping their own unproductive interference. They are simply backing down from where they shouldn’t have been in the first place and they are taking credit while they do so. *Mind Blown*

Truth you came here to find:

The ONLY way to empower someone, is to stop dis-empowering them.

And stop taking credit while doing so. If we do, we are again not really giving them the credit they deserve while we steal the attention.

A person/group can be “Empowered”, only if they want to be!

The notion of empowering a being or a group also creates an illusion that it’s in our control. Sadly it isn’t. Fact it, if a person/group doesn’t want to be, we cannot really make them. It’s a personality trait where some like to do what they have been told.

What sort of person wouldn’t want to be empowered you ask?

  • “I did what I was asked, ask X who owns it now”. Silos – yes, some do love it and it’s all personal.
  • “Trust me I want to help but last time when I tried, your manager turned on me and requested me to mind my own business” – Fear of rejection.
  • “I told you this wouldn’t work. I can help you if you like? No? Alright then” – Ignorance of Skilled opinion over superiority.
  • “No, don’t want to get involved again. Last time I made a mistake and it affected my bonus. It was not even my domain of work.” – Outdated and demoralising KPIs

What can we do about it? Surely we can do something to Empower as Leaders

There are many ways obviously. I have found the following are good enough to start with –

  • Give them an achievable goal and back off. Support and Serve. Delegate and show trust. Allow failure that can be reversed. Make sure they understand they failed and ask them what they learned from it. REPEAT.
  • Find out what the impediments are and why can’t they remove it themselves. Let them try. If they ask for help, without passing a judgement first sort it out. Revisit on how much more we can/should do to remove the blockers in future. REPEAT.
  • Tailor our KPIs based on Team goals over individual performances. If we really care, let peer pressure handle it and monitor how are they performing as a team.

 

And yes, we should stop empowering people or tell ourselves that we can somehow.

As leaders, create a sustainable culture where people can Empower themselves.

Lead time & Flow efficiency measures a system’s Efficiency – Not Effectiveness

Featured | Posted by

X: We have to improve our Flow efficiency & Lead time.

Me: How come? Our Flow efficiency is around 50% which is actually better than most development teams.

X: Yes it’s above average but still not reflecting on the revenue though. We need to improve it even more, some even have 80% which I think we need.

Me: I have my doubts. We have made the system as lean as we could. If we push too hard, we will start hitting bottlenecks. Also we are not a manufacturing company so we have no choice but to keep experimenting new features.

Neither of us above were totally wrong. We simply had different opinions towards what was important for the business under discussion. “Business” – what kind and why it exists is very important here. Not all businesses can achieve high flow efficiency as they have to experiment too much and fail many times to understand the end user’s real problem. Value is what we want to focus on. To make sense of this article let me define what efficient and effective means to me:

Efficient – Moving from A to B within a predictable system and defined route, repeatedly. (Manufacturing)

Effective – Starting from A with no idea where B is and identifying several options to get to B or C or D. (Development)

My views comes directly from few known facts –

“Nothing is less productive than to make more efficient what should not be done at all” – Peter Drucker

“Simplicity–the art of maximizing the amount of work not done–is essential” – Agile Manifesto, Principle #10

An Efficient system (simplified)

This (below image) is what we can think of when we talk about an efficient lean system with reduced waste. Vast majority of the system is being used to work with a good Flow efficiency of around 80%.

There are few prerequisites that we often ignore. The most important one is “Predictable” work flow. We can plan to remove every muda (waste) we find and can end up in an extremely lean and efficient work flow that produces a desired output with perfection. Problem with that is, we assume the same Lean principle applies to every knowledge work which cannot be predicted at all. All we can really do is to project a trend based on historical data and come up with an average, which again may or may not be useful.

If the Business is about making predictable product with TQM and adherence towards a specific output repeatedly, higher Flow efficiency is a must. This is hence necessary for every manufacturing business where development (R&D) phases usually exist out of the structured and well defined lean system to meet the high demand of a predictable product.

A sudo-Effective system (simplified)

sudo-Effective: An efficiency focused system confused as an effective one while trying to use Flow efficiency & Lead time as their KPI.

This (below image) is what we can think of when we talk about a sudo-effective & partially adaptive system. Vast majority of the system is NOT being used to work with a rather poor Flow efficiency of around 20%.

In the above example, the Discovery & Prioritisation is shown as a separate phase which is true for many companies. A request from a customer or stakeholder stays on a product backlog for quite a long time without getting prioritised for months. When it eventually gets prioritised, it might be too late and may have lost it’s intended value completely. I am pretty sure a majority will relate to this example as this is the naked truth of majority of so-called “Agile” departments of an organisation.

An Effective system (simplified)

This (below image) is what we can think of when we talk about a truly effective & highly adaptive (agile) system. Vast majority of the system is being used to work but in extremely unpredictable fashion with overlapping development phases. The majority of the system is focused on doing the “right thing” and frantically experimenting all possible outcomes and collecting feedback on the go.

Are we building the right product?

This question is being asked, as the business regularly faces the challenge of changing requirements heavily influenced by continuously improving competition and their new products. It’s neither predictable nor has an option to make it lean by removing waste. In fact, it is full of wastes that the system is actively creating to learn what doesn’t work.

The Flow efficiency can be very hard to establish in such systems making the KPI irrelevant in this case.. working prototypes are the true measure of agility. We shouldn’t measure Flow efficiency when true effectiveness has to be achieved.

Agility is about continuous adaptation, Lean is about perfecting an adaptation. Providing value is a common goal for both, in very different context.

Some recently posted wisdom from influential & respected community members around it:

Value – Define what it means for the Business in context!

Be it Lean or Agile principles, both defines Value as end user consumable products/services. Who the end user is, defines what the Value might be and therefore what principles to follow to provide that value.

Few example of industries and recommended focus

 

Product Development aka R&D – Based on current generation’s need we have seen time and again that being adaptive is what make or break it. If a development team focuses too much on lean principles to become super efficient, there is a good chance that they forget to consider whether they are really working on the highest priority value according to the customer’s need. They start focusing on processes, tools and intricate mechanics with a partial or complete disregard of the “WHY”.

Hence the recommended focus of such teams and organisation should be to follow Agile principles to become more effective while keeping the necessary efficiency which supports it.

Service Delivery – Any company responsible to provide a part of the system usually 3rd party service providers. consultancies, call centers etc. you name it. Every such industry have very different end users with very specific definition of Value.

For simplicity of explaining, say you are part of an IT consultancy who is responsible to migrate all data from a decade old infrastructure to AWS. There’s a good possibility that the steps necessary for the most part is a mix of finding unknowns and known facts about the migration. End user is the company paying for the service to get it done, a consultancy has quoted a price & date to make it happen. For the consultancy the value hence is defined as “Provide solution by <date> with a £x budget all inclusive.”

To Conclude

There is no right or wrong, just a variable business context and how we define “Value” as.

Sometimes we want to focus on efficiency and sometimes we focus on high effectiveness over efficiency. If you are measuring Lead time or Flow efficiency for a development team, be prepared to get a useless KPI which neither helps you nor the team developing. Measure what is needed to achieve the value rather than trying to fit the same principles everywhere. A simple rule to remember where to apply –

1) When we hear “development” assume obvious complexity, unknowns, learning and adaptation where Lead and Cycle time is very hard to establish.. and at best can be totally wrong. Be agile.

2) When we hear “production/manufacturing” assume predictable known steps with defined output at mass where Lead & Cycle time are extremely useful KPIs. Be lean.

Non-collocation is an Impediment with solutions – exactly like..

Posted on by

While reading the post/comments on an online conversation about non-collocated teams, I felt the need to summarise my views on the discussion separately.

If you don’t believe that non-collocation is a challenging impediment, here are 3 videosto prove that they are.. ALWAYS.

Emails in Real Life

A Conference call in Real Life

Oh you want to do a Video Conferencing? How about all other participants?

You having a lightning fast internet connection doesn’t help remaining participants with speed as low as 2Mbps or worse.

Watch this:

A Video Conference Call in Real Life

Let’s look at the Solutions, to make it work !

Preserving Normality When You Can

  1. Stay in contact
  2. Talk about the mundane, little things
  3. Visit Often
  4. Get to know each other
  5. Remember non-collated team members are humans
  6. Support each other, even over the distance
  7. Create trust
  8. Be committed to each other
  9. Don’t do anything irrational just because you’re angry or upset about something they’ve said or done

Doing Things Together and Bonding

  1. Share something
  2. Do the same things at the same time
  3. Learn together
  4. Make each other feel special
  5. Pursue common interests
  6. Create connection

Setting Expectations and Boundaries

  1. Discuss the nature of your relationship
  2. Talk through doubts, uncertainty, and fear together.
  3. Remain positive.
  4. Have reasonable expectations.

Truth about this Article

Being non-collocated is a challenge and is a reality that we all have to face in this digital world. A long distance relationship have very similar impediments but because we give a shit and we love that person, we try our best to maintain it.

The truth about this article is –

ALL of it’s content are copy/pasted from this Original Source .

 

This original article is about “Long Distance Relationship“ and how we can do our best to keep our loved one closer. After all, that’s all we can do to maintain a healthy relation.

Non-collocation is an Impediment with solutions, exactly like… Long Distance Relationship !

Thankfully, we already know how to deal with those impediments from our personal life experiences. Apply them. The goal is to remove those impediments gradually so the long distance stays a temporary work around. Please don’t make the mistake of asking people work in non-collocated teams for too long.

Definition of Done (DoD) in XDE Framework

Posted on by

In my last post about Definition of Done (DoD) – The Holy Cow Approach, we have seen how “Done” can be misinterpreted just because there is no set definition for everyone. We have ways to deal with DoD by agreeing together what is Done before starting work on a User Story or any form of backlog item. This definition therefore can change depending on context, product, team or even client demand.

What if we don’t have to go through this never ending debate of defining a done for each work item? The internet if full of these discussion, agreement and disagreements which we can live without.

What if, we have a universal DoD which establishes shared understanding company wide?

Definition of Done (DoD) in XDE is a shared understanding

Xtreme Decoupled Engineering (XDE) has a beautiful way of replacing this small talk with something that adds real value – Delivery and End user feedback. In XDE, we don’t need to establish a ground rule about where to stop, before starting a work. We stop and call it Done when we get “a” user feedback – good, bad or neutral. If it’s good we celebrate, if bad we learn and if neutral we let the Product Expert decide where to go from there.

If this is not Simplicity, what is?

 

The One Rule in XDE makes sure we do not get distracted and the Delivery Expert being the Servant Leader of the 1R Team guides the bubble to focus on one work at a time. DoD is therefore universal to all teams and anyone interested to know the ETA of a certain value, don’t have to worry about what “state” it is coming out. It will always come out in a “Ready to Ship” state whenever it is done and wherever it is deployed for the feedback.

DoD in XDE invokes the boundary for Cycle Time measurement

Cycle time is the total time from the start to the end of the development process, which increases predictability especially if we are part of a Service Level Agreement (SLA). DoD in XDE takes help from the One Rule to establish these SLAs with predictable data over time to create a healthy metric to optimise the process. Here’s a visual which summarises how it work:

As we can see, the Cycle time is basically the duration which a 1R team takes to achieve the DoD following One Rule. It also promotes implementation of DevOps by an extreme reduction of multitasking and focusing on the end user feedback.

Conclusion

We have a tendency of making things complicated when there is a simpler solution. XDE’s definition of Done simplifies this ambiguous topic of discussion. An organisation can worry about bigger things which needs attention and teams can work towards the same goal every time like a second nature.

More about XDE: http://www.xdecouple.com

Interested in DevOps? Try Flux with XP practices

Posted on by

Culture, movement or practice whatever you call it, DevOps is beautiful. It ensures the collaboration and communication of software professionals who usually doesn’t think alike in most organisations – the Development team and the Operations team. DevOps practices advocates automation of the process of software delivery and infrastructure changes to align these two. Scalability, security and organised chaos promotes a distributed decision making culture, exactly what we need for being agile.

So which framework best suits us, while adopting this DevOps culture? In my biased opinion I feel it’s eXtreme Programming (XP). It’s brilliant practices/ideas are often borrowed by other frameworks including the concept of “User Stories”. Since most frameworks doesn’t specify these practices, most professionals include XP principles (e.g. TDD, pair programming) anyway. Reason why XP, as a methodology, is underrated and overshadowed by other popular frameworks quite heavily.

Flux framework compliments XP, by adding the concept of decoupled processes and making sure DevOps adoption doesn’t stay just a great idea but is also implemented to save the world 😉

Individuals and interactions OVER processes and tools

“Over” is often read as “Not” by a majority of Agile adopters, who finally starts to realise why agility is far better than many traditional techniques. Is it their mistake? Of course not. Agile Manifesto is quite philosophical and the inclusion of “over” just assumes that the reader won’t translate it to suit their needs. It’s either this or that, not both. If both then to what extent? No one have a definite answer, as it was meant to help evolution which is the beauty of the agile manifesto. But it does scare the organisation trying to transition as not all organisations are consultancies. Not everyone is working for a “client”. Sometimes stability is more important to measure few aspects of the transition. This stability and standardisation of processes is necessary to some extent, as long as it’s not blocking the product development.

No doubt, Individuals and Interactions are important, but it can’t work on it’s own without processes and practices to support the outcome. We need a basic level of standardised processes and practices to accompany this vision of adopting devops to become agile. In fact, most frameworks have vague undocumented processes which are not standardised for all teams. It is extremely unsettling for organisations who are paranoid to begin with. If documented, they are extremely ambiguous, hence often misinterpreted (ref. 1, 2, 3).

XDE complimenting XP – Closing the gaps

I have never seen XP work within immature teams because it needs a sense of responsibility and the urge to know WHY, which only comes from experience. If we ask an immature team to follow XP, they usually try Scrum instead and include TDD and pair programming to call it XP. Mostly because Scrum has a guide which they can refer back to. But there are some subtle differences between XP and Scrum, as documented by Mike Cohn.

When we realise most frameworks are ambiguous about implementing set processes, we often fill in the gaps to support the agile principles ourselves. But during this we may end up in a process which can do more harm than good. By leaving a gap we are letting our mind wander. Most professionals look for the processes first and then learn the principles behind it. Some never care to learn the principles at all, as they assume implementing a framework takes care of everything.

This blind faith and incomplete knowledge promotes half baked assumption of knowing what works and what doesn’t. First we should go by book and then we should focus on mastering it or even bending the rules. XDE tries to close these gaps by formalising the Definition of Done and support to DevOps mindset while advocating the best practices from XP.

Companies trying to adopt DevOps needs a framework which have a set of processes for all teams; is predictable yet highly customisable.

XDE provides that skeleton by defining the start and end of the development lifecycle within the bubble. “Done” for a product increment is defined to include End user feedback – Continuous Delivery plus at least some feedback from users before starting the next work item. It creates a transparent environment of keeping the road map visible at all time by focusing on the value to the end user.

To assure that the Bubble doesn’t start working on the next item in the backlog, XDE introduces One Rule (1R) which creates a process of working on one at a time and only focus on outcome not output.

One Rule (1R) makes sure we are focused on Outcome not Output.

Decouple Processes and Succeed

As we know XDE doesn’t proposes any practices on how the product is built but it recommends XP principles. XP principles with it’s test first approach suits the best but needs a robust stabilising skeleton which XDE provides – hence compliments each other. While the 1R team members work following the One Rule, if a team member is free doing nothing (as they are not allowed to work on anything else) they have no choice but to focus on the ongoing work.

  • “Are you free? Great, get the chair and let’s pair for the rest of the day.”
  • “Yoda is off sick today and we need to review the unit tests before he can start implementing the code tomorrow. Can you do it while you wait?”

Therefore, XDE helps organisation to adopt devops mindset smoothly with the least friction possible and XP assures that the quality of the delivery is spot on and ready for feedback. Try XDE along with XP to initiate the DevOps mindset and help your organisation is agile transformation. Focus on outcome not output.

Agile Transformation – Does it have to be Disruptive?

Posted on by

Agile transformation is the new “thing”, most software delivery businesses are trying to get a grip on. There’s a divide in opinion, facts and politics around it. Many running after the “credit” they get in changing a thing or two to get their names in the list of contributors, which may be soon converted into a tombstone. Others are combining the best practices, changing processes overnight and rebuilding culture to support the sudden changes. Everyone wants a piece of the action but the grave consequences are affecting the business they represent. Why? Because everyone expects it to happen faster, disruptive and trying to change things overnight which wasn’t changed for decades.

Unfortunately the message delivered to them reads like this – “Move into agile methods and you can get more products delivered in the same time”.

 

The most underrated fact around these, when we talk about “Agile” is –

“Agile methods will not double your productivity, in fact it will slow you down to begin with. Agile principles are about providing the sense of creating the most valuable product first.”

The above fact is ignored a lot of time and rouge consultants starts selling “Agile” promising more productivity in compared to Waterfall. Terms get thrown from all sides to the person responsible for budget and a chain of middle management roles wait patiently to get a cut. Members who are not supporting the “movement” either receives a calendar invite from HR or get clinically radicalised to the new religion “Agile”. Why are we trying to do Agile? No idea.

Disruption = Difference in Opinion

 

.If this difference in opinion is not resolved, you can never become agile as it depends on the organisation maturity in every aspect. Reason why many of us heard the phrase “Culture change” thrown at us during an agile transformation. A new bread of management leads the bandwagon towards a belief that doing agile will resolve all problems, improve output and finish project early. But here’s a subtle difference which establishes the Value to the business –

Output ≠ Outcome

 

Outcome may or may not be an intended feature, it can be a lesson which we learn from a failure in an iteration. Some might wonder – “What’s the value of this lesson from a failure which is not generating any revenue?” Well, as an example, a failure can teach us how ridiculous a feature is to begin with, so we don’t invest in future iterations of the feature. Hence reducing the risk of creating a worthless product based on the failed iteration which can be a short term success and a long term burden for a business.

Agile transformation, hence, should reflect a sense of purpose of what we are doing and WHY we have to do it. If, as an organisation we are unable to share the big picture to all employees, there is no way we can be agile in a distant future. Agility is not about implementing a framework or method or tool in place and hope for the best. It’s about self evaluation as a company to learn what we can or cannot do, accepting the limits and exposing the barriers which stops us from being agile. We execute, learn and improve.

The best agile transformations are gradual, slow and have a good amount of time invested in learning while we try to move away from the traditional approaches.

On the Contrary, there are exceptions where Disruption is the Only way!

Gradual improvements are welcome where there is no need for drastic change. But in some organisations this empathetic mindset can be taken for granted. We will find personalities who are extremely qualified and have a very good knowledge of what is right. But milking it seems a better idea for them rather than improvements while exploiting the same knowledge of agile transformation. This is especially true if they are not a “Permy”, as their political existence is based on how long they can stretch the project to get maximum benefit out of a contract/temporary role.

I would be wrong, if I say all contractors are like this. Of course not. In fact, most team level contractors are exceptionally brilliant and embrace agility. The issue starts when we have the middle management as a contractor, who can influence crucial business decisions. These personalities will not harm the business but won’t improve it either. They will keep it as it is and in the name of “Agile Transformation” the project can last for years to come.

Agile Transformation doesn’t happen in a quarter, but it shouldn’t take over a year either.

 

If it takes more than a year with low or no relevant value delivered, we can be dead sure that it is being prevented by a crucial impediment, a process or a personality on power. It can be anything. A year long transformation should be a warning that, not everyone is on board. In these situations, empathy should be shown to personalities who are on board and the rest should be disrupted to make a crucial business decision.

Do you feel the same way?

Which version of the transformation have you experienced/experiencing? Would love to hear your thoughts on this.