Friday, April 25, 2014

The benefits of Scrum come naturally

The benefits of Scrum come naturally if you keep the practices and understand the Agile principles behind them. 

The ceremonies and artifacts performed each sprint, combined with regular inspection, adaptation, and transparency, motivate the Team to get into "The Flow". In turn, "The Flow" allows the Team to surmount any obstacle, getting better and better at each iteration.

As long as we learn and grow, the team enjoys what it does. When the team enjoys what it does, it delivers an enjoyable product. The end of each sprint makes the Team look forward to the next sprint. We go home highly satisfied.

See also: Shu ha ri.

How to learn scrum more effectively - shu ha ri

When I was trying to learn tennis, my coach taught me to first focus on my form before even trying to hit the ball. 

"Just go through the motions and don't worry about returning the ball," he would say. 

Then he'd lob a ball at me and I felt silly swinging my racket, missing the ball by a foot or more. I had lots of questions, but it was more important to practice the sidestep and the swing, he said.

Learning Scrum is much the same thing. First you struggle with the rules. You just go through the motions and feel silly. But the books said to do this and not that. Why is that? There is much questioning and helplessness at this stage.

Part of the difficulty of my first Scrum Team's transition was that I was coming from 15 years of project management tradition. We had doubt, lacked confidence, and had questions like:
  • On time boxing. What do you mean no deadline extension? What happens if we don't finish things?
  • On the Product Owner (PO) making the product decisions and priorities. What happened to the Project Manager (PM)? Don't developers have a say on this? What if the PO is clueless on technology?
  • On testing: My goal is to become a programmer so why should I do my own testing? Testing should be done by someone else because I know my program too well.
Many of these questions turned out to be misconceptions carried over from a PMBOK tradition. 

Here are two important lessons I learned during this critical transition.
  1. You need a Scrum/Agile coach. Just like a basketball team needs a good coach, your Scrum team needs a good coach to guide you when you're groping blindly in the dark, to cheer you up when your team is feeling helpless, and to challenge you to perform more when you start to get bored.
  2. Remember the principle of shu ha ri
  • Shu - trust and follow the rules. Achieve mastery by focusing on just one way of doing things.
  • Ha - break the rules. Branch out and learn from other masters. Experiment.
  • Ri - be the rules. Adapt Scrum according to your own needs.

Looking back at my learning process, I realized shu ha ri was happening. 

Chapter Shu. At the start, we were just going through the motions, like renaming our feature list to "product backlog," tracking burndown charts --  without really understanding why. We were trying to approach Scrum from the wrong perspective of PMBOK. 

Lots of questions came out of this plodding along and I felt I needed to understand more. I read up on Scrum. Discussed with the team, felt we grew a little, but it still felt wanting. Which brings me to...

Chapter Ha. Feeling helpless, I enrolled in a Scrum Alliance course conducted by Bas Vodde. I must have had lightbulbs in my head popping every five minutes in that course. Bas's lessons started linked back Scrum and Agile to lean principles and knowledge management -- a domain I knew well as a management practitioner. 

Bas rekindled in me the meaning of the Agile manifesto and the values that drew me to Scrum in the first place. I was reborn and ready to impart what I learned. And I had lots of practice, working with private and government Scrum teams.

Chapter Ri. What I love about teaching is that I get tons of questions that help me sharpen my knowledge. I enjoy answering the usual ones, but I look out for the surprise questions, the challenging ones like: what do we do if we discover a new requirement in the middle of the sprint? Is it possible to do a Scrum with outsourced team members? Do we have to do the scrum on a daily basis? Can we do the daily scrum via Skype?

As I worked with various teams, my understanding and confidence grew deeper. I evolved a style that could switch depending on the team. 
  • I could be a hardliner, pulling rank and experience for teams that are just starting up. 
  • I could switch to a nurturing coach that allows the team to make its own decisions. My role here is to just give my observations and suggestions and let the team form its own solutions, cautioning them about risks and nudging them towards the right direction when they need it.

"Before I had studied Zen for thirty years, I saw mountains as mountains, and waters as waters. When I arrived at a more intimate knowledge, I came to the point where I saw that mountains are not mountains, and waters are not waters. But now that I have got its very substance I am at rest. For it's just that I see mountains once again as mountains, and waters once again as waters." 
-- Ch'uan Teng Lu, The Way of Zen

Monday, February 17, 2014

Scaling QA using just-in-time QA for Agile teams

I'm often asked how to integrate QA into sprints, especially for teams transitioning to Agile and have limited QA people (eg., 1 QA for 10 developers).

JIT (just-in-time) QA is one good way to do this. The QA acts as a consultant for the team/s and is brought in early into the process, as early as the planning stage. This also develops a QA mindset among the developers themselves as they begin programming while mindful of bugs to anticipate ("Begin with the end in mind!").

Here's how Atlassian does JIT QA: http://blogs.atlassian.com/2013/12/jira-qa-process/

What to do when you've got a virtual scrum team

Scrum and Agile are suddenly popular in Asia, and because a lot of companies take on outsourced projects, they usually have virtual teams, w...