Skip to content

An approach to Scrum

2011 December 19
by Ashish Gupta

I really liked this post from Jeff Sutherland in Yahoo groups. I believe in the approach Jeff mentions here and it applies well to my own context and works well. To preserve it and to promote it I am copying it here verbatim. You can check more on the role of Scrum Master here in Scrum Guide. In Jeff’s case, he as a CEO also pull’s from the backlog which will not apply to larger organizations. I also suggest that Scrum Master should escalate impediments to management when appropriate specially those political in nature.

Since 1993, every Scrum team in every one of my company’s had a ScrumMaster working on the sprint backlog.

The ScrumMaster (or any other team member) does not commit to specific backlog items. The team as a whole forecasts that they will get it done.

When the ScrumMaster has time he pulls from the sprint backlog. For the first ScrumMaster, John Scumniotales, this was 80% of the time by design. As his manager and Chief Engineer I was offloading all his impediments.

In my last company the rule was that in any daily meeting if the team sees the ScrumMaster is not spending enough time on impediments, the team takes the ScrumMaster’s work away from him or her.

This worked quite well. I would never run a Scrum today without this policy.

In my company today, everyone is on the team including Product Owner and ScrumMaster. As CEO I am pulling from the backlog as well. I hold the ScrumMaster accountable for velocity and she has increased it by over 500% this year, while still working on backlog items herself. We have a great Product Owner also working on the team. While I hold the Product Owner accountable for revenue, her clarity and focus on the backlog has enabled the ScrumMaster to achieve her goal – generate a hyperproductive team.
– Jeff Sutherland

Building Software that Users want

2011 October 14
by Ashish Gupta

They stopped treating software development activity as a contractual exercise in which one group agreed to deliver on the specification of another group, and instead worked to a set of shared objectives in which the scope, plans changed and solution changed over time as everyone became more aware of what would actually satisfy users, what it would really cost, and how it could be achieved. – by Walker Royce and Neil Ward-Dutton

We want to build a product that would satisfy users and that user would want. This requires new collaborative way of working on the requirements and solutions, and getting quality feedback, and improving the product based on the feedback. Agile reduces the cost of change, incorporates frequent PDCA cycle and makes us fail faster if we are wrong.

We need to reduce the probability of being wrong and building the wrong product. I present here 3 approaches to accomplish that.

1) Traditional Scrum Product Owner (PO) – In this model PO is final decision maker. He hands out requirements and priorities to the development team. Development team delivers product as soon as possible in small increments of 1 – 4 weeks. In this approach,

  • PO decides “Who and What and Why”
  • Team decides “How”

I raised issues with this approach in A Scrum Story and why it failed. This approach usually works where problem is well understood and solution is not new but it does not  work where creative solution is needed.

2) Team is Product Owner (PO): Whole team works as product owner for the “new new product development”. Team is cross functional, has understanding of domain and customer needs, and is self organizing. Team collaborates with customers, product managers and users. I suggested this approach in my quality of feedback post.

  • Customer & Users decides “Problem and resaon (Why)”
  • Team, working with customers and users, decides “Solution (Who, What and How)”

3) Requester-Collaboration-Responder: This is suggested by Tobias Mayer in his Dogma Free Scrum presentation. I came across it yesterday. I was reaching to this conclusion myself as an extension of “Team is PO” approach but Tobias is ahead of me on these thoughts. Here is more from Tobias on this,

  • Requester  –  “Why” (The reason. The customer. The desired value.)
  • Collaboration space gives – WHAT (the suggested solution, arrived at through requester/ responder dialog and collaboration).
  • Responder/s – HOW – “The tools, techniques and methods the team will use to meet the request” ( from Tobias Mayer’s Presentation.)

There is a mindset shift from command and control style to more collaborative. It is no longer  “…a contractual exercise in which one group agreed to deliver on the specification of another group…” but a collaborative and immersive team approach.

(As another part of the solution to building software that users want, I discussed quality of feedback issue and solution in Agile and PDCA cycle in my previous post.)




Quality of feedback is very important

2011 October 8
by Ashish Gupta

We may be doing perfect Scrum but it can still fail and we may not know it till very late just like in waterfall, as my earlier blog post showed.

Scrum and other Agile iterative methodologies are step in the right direction as they made the feedback loop much sooner and much more frequent. What we miss often is that the quality of this feedback is very important.

Without quality feedback, Scrum or any agile methodology will be an iterative march to failure or at best a mediocre product.

For somewhat new product development

Some things I have done in past to improve the quality of feedback:

  1. Use your own product. We use our own software Agilewrap, a Agile Project Management Software, for managing software development, product management and marketing. This software was born out our own experiences in the field as practitioners of Agile.
  2. Get the prototype in the hands of beta users as soon as possible. Get feedback and act on it where appropriate (Say no where appropriate).
  3. Encourage engineers to sit and listen to end user calls.  Watch end user use the prototype or the product. Quite a few ‘Aha’ moments come when you see users use your product. Product owner and development manager should facilitate this. Do not depend solely on market surveys.
  4. Product owner should be deeply engaged with development team and encourage them to give feedback on product design.  Product owner should be part of  cross functional self organizing team and not a person external to the team. If he is coming and handing over requirements to the development team, that is falling back on waterfall paradigm of a relay race.
  5. Invite end users to your demo/review meetings.
  6. Invite people from other departments – sales, customer support, operations etc. In many cases support and operations teams are also your customers. A lot of people miss this important segment as customers.
  7. Practice Genchi Genbutsu. Getting customer feedback, though very important,  is not same as practicing genchi genbutsu. Direct observation is important.

Example of Genchi Genbutsu

Few months back we received a feature request from a customer to enhance “Export to Excel” feature. We called him to find out why he needed it. He mentioned that he exports data from our tool AgileWrap to manipulate data and he needs this enhancement to make his job easier. We set up a screen sharing session for him to show us how he is using this feature.  I, as a technical person, was on the call with my product person. This observation was an ‘Aha’ moment and we discovered a major short coming of our tool. Next 2 days we worked day and night to enhance user stories screen in AgileWrap so that this customer no longer needed to use Excel spreadsheet.

If we had just relied on customer request and feedback we would have enhanced the “Export to Excel” feature and had not solved the core issue. By directly observing him do the work we enhanced the product so that user no longer had to export to spreadsheet and manipulate it. This was practicing genchi genbutsu and not just relying on customer feedback.

For new new product development

What if you are building something really innovative like Ipod or Ipad where most real end users may not even know how to respond. Some of the suggestions I gave above may not apply. Best solution I have found so far is what is advocated in “New New Product Development Game” by Takeuchi and Nonaka. Build your team very carefully. Have people inside your organization who are able to provide high quality feedback.

We carefully pick the team members after long deliberations.

A project team consisting of members with varying functional specializations, thought process, and behavior patterns carries out new product development.

(Both quotes from New New Product Development Game by Takeuchi and Nonaka.)

Build a self organizing, cross functional, highly competent team. Management provides broad goals to the team, provides oversight and exercises subtle forms of control and supervision. Whole team works as product owner for the “new new product development”. Even in whole team as PO, in practice, team will self organize and one or two people in the team will take on the active PO role.  There is no designated product owner thus no risk of him becoming the weakest link or single point of failure.


A Scrum Story

2011 September 30
by Ashish Gupta

Scrum failed here. The development teams in this company built  products that market did not want. How can the process/framework be successful if end result is failure. The reason there were some productivity gains with Scrum was because the company went from no process to some process. Because of Scrum, management got day to day visibility into what engineers were doing.  Earlier that visibility and control was missing.

Company had remarkable technical talent, trust, self organizing team and a great work culture even before they adopted Scrum. Company had top notch Scrum Coaches and Scrum Masters and used the best agile tool. It was as perfect a Scrum as it could be. Scrum was inconsequential to the end result.

If you are going to fail,  Scrum can make you fail faster. Even that did not happen here. It took years before company realized its products had failed.

So what was the missing piece. Why did not company realize till very late that their products failed?  After all they were Agile and doing Scrum so very perfectly.

Scrum development teams builds what product owner and management asks them to build. Scrum Teams are only self organizing to the level that they can decide on “How to build it. And who will work on which task.” Detailed requirements are often given to the Scrum development team. Requirements may or may not be documented. Scrum teams often do not do much upfront architecture and design and take on a lot of technical debt. But technical debt is a topic for a different story. Here the products did not fail because of technical debt nor did they fail for lack of quality.

NHL great Wayne Gretzky stated: “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”

Scrum  can you help you run faster but cannot tell  you where the puck is going to be. Also scrum or agile is only as good as the people that work on the team. You need to know where are you going.

Wait, you say, what about all the Agile and adaptive thing we have been hearing about. What about review meetings and Retrospective, you ask. After all Agile and Scrum are based on Deming’s PDCA cycle. It is supposed to be adaptive. Why did not review meetings and retrospectives catch these issues sooner?

Because the same Product Owner who gave the requirements was the one sitting in the demo/ review meeting and he got what he had asked for. He was not the final end user of the product. He was only a representative. And product owner did not go out and showed it to the end user soon enough.

So when do the real end user sees and gets to use the product?

Even if you are doing scrum or agile, consider showing to end user and have real end user test drive the working prototype  as soon as possible and get feedback. If you can do it end of every iteration very good else do it as soon as you have a reasonable prototype ready. In many cases end user is external and it may not be possible. Then get them to come to your usability lab and test drive the product or provide a limited beta.

I have even seen one case where end users said they are fine with product when they played with prototype or saw demo. When exactly the same thing showed up as finished product and they had to use it for their work they hated it.  Our Scrum Master said ” We have been demonstrating it to you every month and you just had cosmetic changes. And now how can you hate the end product?”

Invite end users to use beta product as soon as possible and get their feedback.

Sooner and more frequently we get the feedback from the right people the sooner we can fix it. Sometimes the right person to give quality feedback is product owner but many times he is not.

(This story is based on real life experiences and a real life company. Conclusion is mine. )

Update: As solution to the problem I raised above – I have two new posts – Quality of Feedback is important and Building Software that users want