scrum – Page 2 – Rajat Bhalla

Scrum Roles

Scrum is by far the most popular framework under the umbrella of Agile software development frameworks. It allows for greater visibility to product sponsors while allowing the development teams to build incrementally and iteratively.

For Scrum to be successful, it needs a certain degree of discipline. That discipline requires that team members have specific roles and responsibilities even when they are encouraged to be cross-functional and support other team members from time to time.

Scrum defines 3 roles – Product Owner (PO), ScrumMaster (SM), and Team.

The PO is what it sounds like. This person owns the product from a functional perspective. He writes the user stories and puts them into the backlog. Before each Sprint, he refines the backlog to ensure that the stories are the right size in terms of effort and complexity for the development team to work on. He ensures that the backlog is prioritised at all times (highest priority stories at the top of the backlog and lowest at the bottom). He frequently grooms the backlog akin to grooming a garden – removes stories which would not be required in the future, adding new stories to the backlog, and refining the ones already on it. Whenever, the team seeks any clarification on the functionality or the priority of the stories, he is their go-to guy.

The way a PO owns the product, the SM owns the process. While the PO ensures that the team build the right product, the SM ensures that the team builds the product right. He works with the PO in ensuring that the all meetings required to make the product and process smoother (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are held regularly and in the right spirit. He makes sure that the development team is not pressurised into taking on more work than they can handle. While the PO is busy gathering and giving feedback about the product, the SM does so for the process.

The third and equally important role is that of the Team. The Team comprises of anyone and everyone working on the product technically. It includes developers, UI designers, and testers. They are responsible for building the product as per the acceptance criteria specified by the PO while following the process set by the SM. They own the quality of the product. They have a right to take on only as much work as they can finish in a Sprint without compromising on quality. They are also welcome to request the PO to include stories that would benefit the product quality and maintainability.

Together, the three roles in a scrum form the 3 sides of the project pyramid and offer great stability to the development process. Together, they ensure that the right product is being built right. If any role takes on a weak or a dominating stance in the team, the project suffers. Thus, it is imperative for each of these three engines to fire consistently in order to move the ship forward.

The team is also referred to as “Pigs” (because they are committed to the project) while the PO and SM are referred as “Chickens” (because they are just involved). The following image lends context to this nomenclature.

Agile

Agility @ Appster

As on today, I am working with Appster as an Agile Coach and Senior Project Manager. Here’s what I have to say about the process we are following at Appster.

In order to build a great product, you need to have a greater process. A process that is simple yet flexible. A process that lays emphasis on quality yet allows change as you go. Agile emerged as an answer to this need. It is a software development framework suited to humans – people cannot predict the future accurately and would like changes to be accommodated in their plans; humans can focus only one or two items at the same time and not the whole gamut. A quick look at the Agile Manifesto assures one to the flexibility inherent in an Agile development environment.

At Appster, we are trying to imbibe the spirit of Agile in its purest form. It all begins with the signing of an Agile contract with the client. The client is not bound into an iron-clad contract (reminiscent of the Waterfall model of software development) but allowed to make changes to it as long as the primary constraint (scope / time / cost) is unaffected.

The client’s requirements are captured not in an exhaustive document covering reams of paper but into high level User Stories (called as Epics). Epics allow the client to express the desired functionality easily while leaving enough room for change / discussions.

Then the dev team breaks down these epics into smaller User Stories that are the right size for development and planning. The entire development is broken down into two-week long iterations called Sprints. At the beginning of each Sprint, the highest priority User Stories are discussed in detail and planned to be completed during that Sprint. The design, development, and testing for each User Story is encompassed within the Sprint only. This is in sharp contrast to Waterfall development wherein each of these was a phase in itself. At the end of the Sprint, the client is presented with working software in the form of a build. While the client does User Acceptance Testing of the build, the team retrospects about how it performed in the last Sprint and what improvements it can include in future Sprints.

During the development, the client is welcome to change any requirement for which work hasn’t started already. The client is free to make changes inline with the scope / timeline agreed upon. The team approaches client interaction with a mindset of collaboration rather than contract negotiation. Even changes that are beyond the contract are acceptable if both the parties are willing.

The above process allows the dev team to deliver working software frequently and in increments. It allows the client to be deeply involved with the development process and see his app take shape and grow like a tree. It also allows (and even welcomes) changes to the application that make it relevant to the current situation of the market and competition.

Agile

Detailing Backlog Appropriately

On one of the projects I am managing currently, I noticed that the product backlog was actually growing rather than shrinking as we were progressing through sprints. At one point, there were close to hundred and fifty stories in the backlog, all detailed and ready for planning. Some were even accompanied by ready UI-designs. The reason for the increasing backlog size was that everything under the sun was being thrown into it for future development. While this might sound fine (you would want to write down somewhere the features you might need in the future and what better place to write them down than the backlog), there was something definitely going wrong.

I realised that every time we would plan a new sprint, instead of picking previously written stories from the backlog, we were writing new stories as the client had come up with a new feature that had priority over rest of the backlog. This is completely understandable and even recommended. After all, you would like to use the feedback you are receiving from the market to add new features. If the window of opportunity for a new feature is now, no point putting it on a backlog for later. It requires attention now. But what about all the stories (and the effort invested in detailing them and designing the UI for them) in the backlog? Soon they would become obsolete. They would never see the light of the day. If at all their turn would come, they would require changes (in both the functionality and the UI expected) as the current functionality would have undergone a change by then. In terms of Lean thinking, this was clearly muda (“waste in Japanese). I could have done better things with the time I invested in detailing those stories and helping create their UI-design.

The other day, I was watching a show on some television channel (I think it was Comedy Central) and I noticed the way they presented their schedule:

Now (the show currently being telecast)
Later (the show after the current one)
Never (the show after the “later” one)

This was a fun way to provide a relative schedule, especially the “never” part. Considering that I am always in a “meta” state of mind looking at things above their current context and trying to correlate aspects from different contexts, the schedule format hit me as a solution to my backlog problem.

While the stories in the current and immediate next sprint (“Now” part of the backlog) would be detailed enough, the stories in the next two to three sprints (“Later” part of the backlog) would be relatively coarse grained. Stories even further down in the backlog (“Never” part of the backlog) would have no detail whatsoever. They could be as simple as a single line, five-word statement (similar to epics in Scrum parlance). This would help the backlog stay current and sharp, help me focus my time on more important tasks, and reduce waste. Of course, we would continue to add to the backlog any item we “might” need in the future but it would not be as detailed as before, it would simply be a reminder, like a to-do.

Agile, Automobiles

If Scrum was a Motorbike

Scrum and motorbikes, two things that I am very passionate about. Subconsciously, I could sense a parallel between them. When I actively thought about it, the picture became clearer.

Consider the Team (developers, UI designers, testers) in Scrum. Its mandate is to deliver a working increment each iteration. It is what powers the product / project. It is similar to the engine of a motorbike. It converts stored up energy (in the form of fuel) into motion that drives the whole. Akin to a Scrum team, it delivers usable power each cycle of the n-stroke engine. Similar to a Scrum team that iterates over the backlog, the engine iterates over the strokes in each cycle. The way an engine gobbles up fuel to deliver power, the team completes stories from the backlog to deliver a working software.

Now you don’t need to be a gear-head to know the importance of keeping the engine well oiled. That is where the ScrumMaster fits in. He is the engine oil. The oil keeps the engine running smoothly, lubricating it, ensuring that there is no grinding against the metal. Similarly, the ScumMaster keeps the team protected of outside interference, ensures that there are no impediments in the progress, that the team is not overloaded, that there is no grinding between the team members. He keeps the team running smoothly. A good engine oil keeps the parts well lubricated even when the engine is running at a high RPM, the temperature is high, the stress is high. Similarly, a good ScrumMaster ensure that the practices are followed even when the team is under stress (the scenario of the team being under stress is infrequent but possible when the team commits to deliver more than they can complete so as to meet the aggressive goal).

Where does the Product Owner fit in? I believe he is like the handlebar of the motorcycle. The product owner provides direction to the team. It leads the team to the intended goal. If the team deviates, it provides correction (during Sprint Reviews) so that the overall destination can be reached. The way a handlebar can be used to avoid obstacles along the path, the product owner can clarify the doubts of the team to keep them focussed on the right goal.

Of course, there are a lot of other parts in a motorcycle, and many more and varied parallels can be drawn, but this is what struck me. If you keep the above in prime condition, you can assure yourself of a smooth journey. Ride hard, ride well.

Agile

Becoming a Certified Scrum Professional

Considering the increasing number of companies practicing Agile, getting a ScrumMaster on the rolls has almost become mandatory. Consequently, lot of people (including PMPs) are getting themselves certified as ScrumMaster (or Certified Scrum Developers / Certified Scrum Product Owners) . After two days training and passing the exam, they consider the job done. If you are one of them, then your journey has only started, my friend.

While becoming a Certified ScrumMaster is relatively simple and straightforward, becoming a Certified Scrum Professional is a different ballgame altogether. If you pay attention during the two day training, you can pass the CSM exam with flying colours. CSP, however requires constant practice. If the input for the CSM exam was theory, then its practice is the input for CSP exam. Consider an analogy – most of us would have studied trigonometry in school or college; how many of us can find the distance to an object close by using triangulation. The inability stems from lack of practice.

CSM training throws a lot of jargons at you – product backlog, burndown chart, sprint planning, etc. It all sounds great during the training. You understand it and take the exam. Get certified and then sit back and relax. Not so fast, mate.

The two-day training should act as only an appetiser. You are yet to enjoy your full course as part of the on-job-training when you practice what you have learnt. You may have a product backlog but you don’t’ spend enough time grooming it. You practice sprints but every once in a while you let it extend for a day or two as the team wasn’t able to finish everything they had committed. You estimate stories but the estimates are not provided by the team. I remember talking to a friend who, on knowing that my company practiced Agile, was boasting about the Agile practices at his company. I simply asked, “who estimates the stories”. Prompt came the reply, “the client”! I wish we were talking face to face rather than on phone and he could see my jaw drop.

Even though the title of the certification has only “Scrum” in it, it also requires a fair brush with methodologies that go well with Scrum, for example eXtreme Programming (XP). I don’t really think that Scrum talks about automation or test driven development but you can’t be fully Agile without it. Lean thinking again works well with Scrum. “Lean inventories” is mirrored in Scrum by having stories detailed just enough to drive conversations, to have stories only higher up in the backlog as detailed and the lower ones as coarse grained. Yes, you learnt about it during your CSM training, but are you practicing it?

ScrumAlliance provides a list of books / articles, one should be well versed with before taking the CSP exam. But that is only a guideline (just like the Agile Manifesto). You need to have a good exposure to Agile practices if you want to earn your certification. The questions are not from a theory book. They are based on scenarios. And most of the times, all the options provided are right. Your experience would tell you which option is the best.
When I got certified as a CSM about 3 years back, I thought I knew it all. But today, after receiving my CSP certification, I can say with full confidence that the CSM was only a spark, the noodles were cooked by a steady practice, observing and stirring (or in terms of Agile – inspecting and adapting).

If you have noticed the number of times I have used the word practice in various forms in this article, you would realise what I am trying to tell you. So my humble suggestion to you is to earn your CSP certification by going through the motions of Agile practices. Follow the road amigo, not the steps.