AFTER 11 YEARS OF AGILE, I LEARNT SCRUM AGAIN…

A fascinating thing happened in my life two weeks ago. I went to a three day class with Craig Larman in Toronto. At the end of it, I was totally blown away.

A fascinating thing happened in my life two weeks ago. I went to a three day class with Craig Larman in Toronto. In the end, I was totally blown away, by the simplicity of his thought process and its ensuing answers. There he was with his signature tie and boots, being exactly as Craig himself, the person he is encoded to be.

Not that I found religion of some sort, perhaps, but Craig was particular to point out multiple times that his approach was not based on religion, but on science. As I abhor complexity, I continue on a journey to finding simple answers that answer complex problems, by design. And in this journey I found more in these three days than I have ever in the last decade or more.

During the three day class, Craig spent most of his time on two areas where I always wanted more answers – systems thinking and Agile adoption. Those two were really at the heart of the problem as root causes for most teams and organizations doing Agile than being Agile. He held a mirror to my understanding and it showed me that there were simple answers to how I could assist my teams and organizations that I work with.

Large Scale Scrum (LeSS) and descaling organizations

Mind you, it is paragraph four, where I wanted to point out that the course I attended was on Large Scale Scrum (LeSS) as Craig Larman and Bas Vodde, the co-creators call it. But stepping back, the concepts for Large Scale Scrum spoke equally well for a single team – practices that should be the norm if there was just one Scrum team, because just that was how Scrum was meant to be.

From there it elegantly scales or descales the organizational teams to 2-8 Scrum teams and to 100’s of team’s (LeSS Huge) when there is such a need to support the Product that the organization requires for it to succeed.

But this article is not about descaling, this is about simplicity.

Concept 1: It is all about systems thinking

Well, there are a lot of folks, I mean really lots of folks blabbering about Agile and Scrum and Lean. Gurus of all sorts. I do that too. Drop names like I went to school with Edward Deming and he was my buddy of some sort.  Talk like I am connected to Ken Schwaber though an Avatar Na’vi like mind connection, better than someone else out there in my understanding of it all. Well, the net answer is, it is all in the systems thinking and those who find those answers better than others can help teams and organization succeed at scale.

Concept 2: Adoption

It is not often about Agile, Scrum or XP, SAFe or even LeSS and other frameworks that are used for doing Agile or being Agile. It is that none of them have considered the aspect of how to change. And that part is an important aspect of being Agile. Often ignored, often misunderstood and leads to getting to the results which need another transformation to fix the transformation which was done in the first place.

LeSS adoption methods, its principles and rules lay the groundwork for a proper Agile adoption and this sets the cornerstone for introducing change. A fantastic piece of the missing puzzle in all other frameworks. Agile and Scrum, two key meta frameworks, just lay out it at a high level and tells you to figure it out. And people with their own irrational way of interpreting it with their limited understanding run away and implement it in the most flawed ways possible, mostly due to their ignorance.

I wonder why Ken Schwaber needed his NEXUS system to scale Scrum, was it possibly his ego that prevented him from adopting such a wonderful system like LeSS which has been around for a longer time, and makes more sense that what he has proposed.

In summary:

• The LeSS course is what a Scrum course should be in the first place. Take LeSS and apply its principles and rules to a single team, you have the perfect Scrum team.
• LeSS is simple and descales the organization, if you follow the science, this is the way until you find a better simpler way.
• There is nothing new in LeSS, it uses Scrum as a building block and allows simple concepts to bring together multiple Scrum teams in support of a Product.
• I wonder why Ken Schwaber needed his NEXUS system, was it possibly his ego prevented him from adopting such a wonderful system like LeSS which has been around for a longer time, and makes more sense than what he has proposed.
• It was an important part of my Agile and Scrum journey and is going to be pivoting point in how I do things from here, moving forward…  truly valuable.

This was first published in www.effortLeSSagility.com at http://effortlessagility.com/2016/04/25/after-11-years-of-agile-i-learnt-scrum-again/

 

 

Advertisements

Upgraded Scrum Guide – Finally, about time.

Jeff Sutherland, co-inventor of Scrum

Jeff and Ken decided it was about time to start being a little prescriptive. In a joint announcement today, 1st April 2016, they launched the revised Scrum Guide with some major overdue changes.

While announcing the new version of the Scrum Guide Jeff said “Scrum has been around for more than 20 years. But while we observe what goes on in the industry, it is heavily misused and misinterpreted in more than 99% of its implementation and usage. Study after study after study tells us that though a lot of companies use Scrum, they are just mechanically Agile. The general masses don’t understand that Agile and Scrum is a philosophy that needs to be understood to implement right”

Ken chimed in, “Both Jeff and I believe that a key root cause to the practice of Scrum failing, is insufficient collaboration between Scrum team members and the way they swarm stories

Ken Schwaber, co-inventor of Scrum

to completion. We have therefore added two more ceremonies to the Scrum Guide, which are both prescriptive in some way to help assist with the communication behaviors in teams. With practice of these two ceremonies every day, over a period of time, teams will have increased internal and external communication. The needs for the ceremonies go away over a period of time, as the teams have now learnt on how to collaborate and this has become the standard sustained behavior for the masses”

Here is the summary of key changes that are now available on the Scrum Guide.

New Ceremony: Check-in

• 

  Jeff Sutherland, co-inventor of Scrum

  Apart from the Daily Standup, new additional daily ceremony

• Scheduled by Scrum Master at 11AM, 1 PM, 3 PM and 5 PM (assumes Daily Scrum at 9 AM)
• Duration: 5 minutes
• Participants: Development team, Scrum Master
• Team members provide a status update to other team members on where they are with the completion of the story they are working on. Each team member: 30 seconds.
• Scrum Master notes down impediments and works to resolve outside the meeting.

New Ceremony: Huddle

• This is a second ceremony similar to the Check-in. Apart from the Daily Standup, new additional daily ceremony. This is an either/or Ceremony. Use either Check-in or huddle.
• Scheduled by one of the team members- at 11AM, 1 PM, 3 PM and 5 PM (assumes Daily Scrum at 9 AM)
• Duration: 3 minutes
• Participants: Development team
• Team members provide a status update to each other on where they are with the completion of the story they are working on. Each team member: 20 seconds.
• The team handles the impediments and escalates the required one to the Scrum Master.

Ceremony change: Daily Scrum, the fourth question.

• 

  Ken Schwaber with Jeff Sutherland announcing

  The current Scrum Guide asks each of the Development Team members to articulate the following during the Daily Scrum:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
• After the Daily Standup is complete and each of the Development Team members has spoken to the three questions, the Scrum Master asks the fourth question: “What does it take to SWARM the top priority story/stories to completion (DONE) today?”
• The team has an active conversation to this question, to plan their day in order to complete stories.

Scrum Guides.org

The revised Scrum guide can be found at Scrum Guides. Please read it carefully and practice/implement as it is laid out in the guide. Remember, Scrum is an empirical process and you need to practice all of it, by the book in order to succeed.

This article was first published here in the Journey of an Agile Idiot <.com> and is the original source of this content.

Disclaimers:

Use Scrum at your own risk. No success is guaranteed. Often it may lead to failure. If you succeed, the success is all yours. No need to write checks to anyone to share your success with. And when you fail, you are the cause of that failure, not Scrum or Agile. You may use Scrum and/or Agile and your organization may still may not succeed, may get taken over, go bankrupt or out-of-business. There is a high likelihood of failure happening anyway, whether you use Scrum or Agile or Waterfall or not. Use of Waterfall may accelerate failure and make it more faster. Use the methods stated above in the article based on your own evaluation of its value. If there is merit and you use it, please click Like on this blog or follow me on LinkedIn.  There is no affiliation with Ken and Jeff or to Scrum Guides, implied or otherwise. All copyrights are respected. This article is valid for potential use on 1st April 2016 and expires midnight 1st April 2016. Some call it Idiots day named after and celebrating idiots like me. Contents may not expire and could be used with no side effects, even after that date. Use at your own risk. These changes have been lab tested by dozens of Scrum teams over several years. The only known side effects of these changes include finished work, delivered value, higher quality, reduced stress, early completion of stories, happier Product Owner/Business and happier Scrum teams/Scrum Masters. No animals or babies or children or Scrum teams were harmed in making of these ideas. Do not print the Scrum Guide, use them electronically, save some paper and the planet. Better still, keep it all in your head all the time, so that you can save some utility and network capacity every time you open it on your computer, tablet or phone (that assumes that you actually use the Scrum Guide). Remember, Agile is not fast or quick, the dictionary definition of Agile. Agile may be sometimes slow or slower. Beware, Agile may deliver better quality. Better still, use of Agile methods may increase the chances of your organization actually surviving. All photos used are credited to wherever originally posted and a big thanks to them.

Caught doing right – mindset essential to Scrum success

This is a fairly new team who have just finished their first three-week Sprint. They had their first retrospectives two days ago and started their next Sprint yesterday.

One of the learnings that the team had during Sprint 1, was that their QA was their bottleneck. They had one QA automation engineer on the team and he could automate only 3 of the 10 or so stories they picked for the first Sprint.

The team is in the process of multi-skilling themselves in learning the functional automation toolset, so that all team members, including developers can pitch in with assisting the functional test automation effort. In Sprint 2 planning yesterday, when the task breakdown was completed a few developer hours were still left and these were left unplanned. Though additional development could be done, it creates more WIP that is incomplete at the end of the Sprint. The team realized that it is far more important to get completed work into the hands of the customer than doing some work that doesn’t.

With key Agile concepts ingrained in the team, this team is setup for success for their current work and whatever work is thrown at them.

Key Agile concepts exhibited:
• Multi-skilling is essential to success – all team members are learning to write automated tests
• Reducing WIP is key – there is no point in developing code that cannot be delivered to the customer
• Working retrospectives – active conversations in retrospectives led to solving problems that are key to success – in this case, the team realized that their #1 priority was to complete stories end-to-end with the use of automated testing suite. This “slow down to speed up” approach means that their ability to regress tests as they move forward with development will allow them to move faster as they build more and more functionality.

 

It’s time

It starts with who I am baked to be, and I am really thankful for who I am.  I  am a quintessential problem solver. Understand. Identify simple answers. Implement them. Make them stick. Evaluate results. Evolve them again. My mind swirls with a million questions every day and attempts to find simple answers to several of these questions, all at the same time.

I discovered Agile rather late and started with Scrum in 2005. Not long, but in tech years, 11 years is a long time. As I proceed on this journey as an Enterprise Agile Coach, I see thousands of behavioral patterns and anti-patterns. And from these patterns and anti-patterns emerge larger patterns. A concrete picture emerges. A picture that tells me there is too much complexity where there is no need to be, and I just can’t fathom why.

I like simple answers, not because I can’t handle complex, but because it is unnecessary to make things complex. An answer to solve a few things creates more new problems parked to solve in the future. Clutter. Tech Debt. Accumulation. Over engineering.

As I proceed down this journey, I see Agile plateauing, Scrum being misunderstood, misused and misinterpreted. And I realize the psychology and neuroscience at play in large scale teams and organizations. They behave in exactly the way they are hardwired to be, playing out their biases of right and wrong based on their limited understanding.  And this leads me to ask more new questions like:

• What if the Agile Manifesto is the root cause of all evil – by its lack of clarity and its ambiguity?
• What if Agile as it is today is wrong?
• What if Scrum is wrong in its philosophy preaching to folks who can’t understand it?
• What if the way we go about handling change is wrong?
• Why are we doing what we are doing? And why this way?
• Will this give organizations competitive advantage at all, or still take us on a road to doom?
• What would we do differently, if all these methods and frameworks are wrong?
• What is the best way to coach teams and programs at scale?
• How to ease in change at scale and make it easy and effortless?

Nothing in my journey is sacrosanct or not open to question. I am not wedded to any ideas, methods or approaches, only to those that make sense at that point in time — which very well means that the very next day, there are fresher, better and more simple answers now available.How fast can things change?

My goals are clear, “Better, simple and sustainable by design, evolved every day!”

Join me in my journey of finding these answers and more, in the art of making complex, simple… Chaos mastered by several small simple answers – ideas that are easy to implement and sustain. My goals are clear, “Better, simple and sustainable by design, evolved every day!”. And what is the worst that would happen? I could fail, and I am totally okay with that.

It’s time.