Skip to main content

Autonomy, Self organisation, Respect, Commitment and Self Responsibility (Real Life Example)

For many new to Lean and Agile, the concept of self organised teams or self managed teams is very hard to understand. They simply can not comprehend it. Because they have never experienced it and never thought it is possible. This includes not only senior leadership and managers, but also programmers as well.

When I talk to some ScrumMasters about servant leadership, it is also hard for them to really understand it, especially when they come from traditional project management world of command and control.

In the past couple of days, I was discussing with clients and management about autonomy and self-organised teams a lot. And I thought, I share here a glimpse of a real example of a self organised team. Fresh, hot from today Slack communication of one of the teams I serve happily.


Context:

  • This team is 7 people, Let’s call them Team X,
  • They work with another team on the same backlog. Let’s call them Team Y.
  • Team Y is 6 people.
  • Both teams are cross-functional, and they work hard to share knowledge together and learn more about different part of the system.
  • They work with Operation Team, who takes care of Production releases and maintaining infrastructure. Operation team is four people.
  • They work in a project based company. They develop application for their external clients who act as Product Owners.
  • There is a Product Owner Team. Two main product owners, four product owner supporters, and one Chief Product Owner. 
  • Team X and Y had several changes to their team. Simply, people left to different countries to work or decided to join another company. And new team members joined. There were some challenges at the start, but both teams started to collaborate together effectively very soon. 
  • There were several process improvements also in place. For example:
    • They decided to not commit to their full capacity at the start of each sprint. 
    • They decided to reduce bugs to Zero, and put Zero bug in their Def. of Done. This was a huge change, as previously they had 100+ bugs unresolved with average lead time of 2 months, and max lead time of one year. Today, and after 4 months, they have Zero. And they resolve bugs when they appear. 
    • They also work hard to have ready backlogs at all times, at least for the next 3 Sprints. 
    • They have also adopted pull mechanism. Historically, work was pushed to them by Maintenance Team and Product Owners. They agreed with Product Owners and the rest of the stakeholders that they pull Stories or Work when they are done with in progress ones. 
    • They have done many other improvements as well. But, it is beyond the scope of this blog post to explain them. 

To demonstrate a glimpse of their self-organised nature and autonomy. I wanted to share a conversion that 3 of the programmers had together TODAY on their Slack channel. I have not edited anything here, only names and some sensitive product info changed.


Oh, one more info, They have two weeks Sprint, Their Sprint Review is next Tuesday Morning, and today they were done with committed stories, and were trying to pull in more without any direction or intervention of ScrumMaster or Product Owner. Fully self initiated. 

Read it and see a small example of optionality, selection, autonomy, self organisation, respect, commitment, awareness and self responsibility.


3:30 PM

ZM :what about pulling in Story-3104. I think it can be done on time. What do you think @RR and @VA?


3:40 PM
RR:
@ZM and @VA we can, but we should sit and discuss how to do it


3:41 PM
VA
I'm in gov office. What is that story about?


3:44 PM
ZM
Search: Integrate WeeklyAds results on search. Basically new Tab for the Weekly Ads. It will get the content by javaScript (calling external webservice which returns HTML) but there is another service which will return just the number of results.
when are coming back? will you make it today?
so we can look at it tomorrow morning


3:47 PM
VA:
Yes, I looked at it yesterday. From my opinion, it's mostly about frontend, so I agree to pull it in, but I think that @RR should decide if he has a time. I don't think that I will be in office today because my appointment is at 16-10pm , now I'm waiting.
So to look at it tomorrow morning would be better


4:11 PM
RR:
it’s ok, I finished all bugs, so I have capacity…we can discuss tomorrow morning then.



ZM went through the backlog, and reviewed all possible Options. And He then Selected one of the stories. Then, communicated it with two of his teammates, they all Respected each other's availability. Then, they agreed together to talk about it when they all are in the office. There is no need for anyone to intervene and try to set-up a meeting for them :)



Comments

Popular posts from this blog

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while,

Stay Fitter

1st edition of Fit for Purpose: How Modern Businesses Find, Satisfy, and Keep Customers from David J Anderson and Alexei Zheglov was published in Nov 2017. They wrote the first edition in 7 weeks during summer 2017. I had a chance to provide feedback to them as they were writing and editing their chapters. The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why's of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service. When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson. The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: "B

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe. At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better . The reasons are simple: It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2 And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next! At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and thei