Team Leads or Project Managers as Scrum Masters

In organization after organization, transitioning to Scrum, you see one common pattern. The pattern has existed for at least 03 years now. The pattern is seen in all organizations [at least in India] – established big names as well as upcoming talked about/ blogged about startups. There is a team and there is a Product Owner [or Manager]. So far so good. There is also a Scrum Master – who is also the Project Manager/ Development Manager/ QA Manager/ Program Manager/ Project Lead/ Team Lead/ Developer/ Tester. This raises some questions.

Why is this happening?

I haven’t quite figured out [as yet] why if you are transitioning to Scrum, would you want this to happen – especially when Scrum Master is defined as a full time role in Scrum. The feedback I get is mostly around these lines:

• There are not enough Scrum Masters available. We can’t just keep waiting for them to turn up. Hence, we identify people internally who can play this role. And, no one wants to do this role full time or take on this title officially. So, there we go. Do your 2 plus 2 is 4.
• There does not seem to be any value in this role being a full-time – it is something you can do part-time. How much time can removing obstacles for the team actually take?
• Serving the team, Protecting the team, Helping the team, Guiding the teams use of Scrum is something, which everyone should do and different people are already responsible for these things.

It is easy to dismiss or scoff at these [especially the latter], but these arguments actually seem to be true. I know for a fact that there are not enough Scrum Masters available [possible topic for another blog post]. I also know, that in an organization internally, not enough people are kicked enough to play this role. And, no matter what argument you give, the management is never convinced that this can be a full-time role especially when they see others doing this role.

Is this a good practice?

My views on “doing something just because ABC or some book or some user group discussion says so” are well known. Don’t do it. It is also said, that having no Scrum Master is better than having no Scrum Master. Before we address the question – Is it a good practice for Team Leads/ Project Managers/ Developers to be also Scrum Master, we must see what is it that a Scrum Master does. Like most things, lets start with Wikipedia, “Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverable. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks in hand.” Scrum Masters use soft power, servant leadership and trust to help the team become better. Scrum Masters also surrender complete control to Product Owner and the Team.   Some of the qualities we look for in a Scrum Master are humility, staying in the background, integrity and gain trust. We obviously see the clashing red flags here – the Scrum Master is not a leader. However, typically, the Leads/ Managers are that. The team is reporting to them. However, nothing that we talked about in Scrum Master’s role says that you can not have that with the team reporting to you or you working part-time as a developer/ tester. In fact, some people could argue otherwise. If you are a developer and you are convincing everyone to test, you can lead by example. So, let me stick my neck out and say – “I don’t think it is a bad idea.” It is always better to get the right person play a Scrum Master – like role half time than getting no Scrum Master or lousy full time Scrum Master. However, I won’t probably call them Scrum Master. I’ll call them Scrum Evangelist or Process Owner or Scrum Owner or something like that. Why a different name? Because, the team does not report to Scrum Master [yes, just because of that]. And, anyways, it wont be the name, but the intent and the action of the person that will play out louder in the transition scheme of things. Also, you should get these people [and the rest of the team and Product Owners] good coaching.

Some of these people [Process Owner or Scrum Owner] will make Scrum a bad word in the organization. But, so could many Scrum Masters and Product Owners [and even the teams for that matter]. The hope is that organization will pick the right people for this role. Like the rest of the organization, these people [whatever you have called them] will also transition.

Advertisement

A Sprint Retrospective – The Ideal way to Start Agile

Is the Certified Scrum Master class I attended about 03 years back – Pete Deemer, the Guru who led Yahoo’s adoption of Scrum in multiple locations, said “Even if you did not do anything else but only Sprint Retrospective, you will see tremendous improvements in your process or way of working.” That is, even if you were not doing any of Sprint Planning, Sprint Backlogging, Product Backlogging, Sprint Reviewing or even Daily Stand Upping, you would be doing very well, by doing just one practice – Regular Sprint Retospecting. That is definitely a tall claim. And from my experience in the last 03 years, a true one too.

Let us look at the basics first. What is a Sprint Retrospective? Rather, what is a Retrospective? As per Wikipedia, Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place. For example, the term is used in medicine, describing a look back at a patient’s medical history or lifestyle. It is particularly useful to look at the medicine analogy here. Retrospective, in medicine, means looking back at medical history.  In Software Development, a retrospective means looking back at project history. This is typically, with a team and depending on the context it could include project managers, senior managers, directors, VP’s, whole team, testers, developers, business analysts in any combination. Extending the analogy with medicine further->typically, you will look at the medical history only if something has gone wrong or when the person has died [and you are doing an autopsy]. Unfortunately, most retrospectives in Software Development are also held, when something has gone wrong or at the end of a project. Agile Software Development uses retrospectives, like regular diagnosis [and not just when something bad happens]. After every iteration or sprint, the team gets together to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Agile and Scrum are adaptive processes.Retrospectives and Daily Stand Ups are too practices which enable inspection as well as introspection – both necessary for adaptivity. Even if the team did not do a product backlog or sprint backlog or burndown chart and the team just did regular Sprint Retrospective, what will it unearth? One of the first things, they would probably identify is that we never knew where we are and what everyone is doing or where someone is stuck. They will come up with burndown charts [or some variant/ substitute] as well as more regular meetings [daily stand ups]. More features like sprint planning, sprint reviews, product backlogs etc. could come up. Some things like no change during the sprint could never come up. Hence, the team could come up with their own version of Agile – something that fits them the best.

The above paragraph assumes some critical things:

• The team is empowered and capable to drive a retrospective as well as implement the action plans that are highlighted for the next iterations. Significant management as well as team buy-in for being process leaders rather than process followers is hence, required.
• Given the nature of retrospectives, they can degrade from looking back to blame games quickly. Hence, good facilitation and guidance during a retrospective is required.

Some retrospectives can be more productive than others. We will take a look at more on retrospectives in the future articles. You might also be interested in the Start, Stop, Continue Technique of Agile Retrospectives.

A Practical Guide to Distributed Scrum – Review the Upcoming Book

Distributed Scrum/ Agile teams is one area where most globally distributed teams struggle. There are issues of time zones, cultural nuances and languages apart from other local issues. However, globalization of work and workforce is a 21st century requirement and reality. Implementing Agile brings these differences and issues out in the open even more. A Practical Guide to Distributed Scrum – the Book hopes to provide people implementing Scrum or Agile in a distributed environment with some examples and experience insights. This book has been developed through the collaboration of the IBM Scrum Community [comprising more than 1000 members across 07 business units of IBM in 30 countries]. The book specifically will take a look at these aspects:

• Estimate user stories and work with the Product Owner as a distributed team
• Implement techniques to more efficiently engage in Release and Sprint planning
• Effectively conduct daily Scrum meetings
• Enhance communications between team members throughout the Sprint
• Conduct a productive reflection to improve productivity and quality over the next Sprint
• Demonstrate progress to stakeholders at the end of each Sprint
• Leverage tools to improve the productivity of distributed teams

The book is written by:

Elizabeth Woodward who is a Senior Software Consultant with IBM Quality Software Engineering under the office of Innovation and Technology.

Dr. Matthew Ganis is an IBM STSM and ibm.com site architect. Matt is the co-creator of the Agile@IBM community and was an early adopter of agile within IBM.

Steffan Surdek is a User Experience Lead and Agile Champion in IBM.

You can help review the early drafts of the book at Distributed Scrum website.

Agile and Scrum Jobs in India : Beginning to Appear?

It seems after about 03 years of activity on the Agile and Scrum jobs are beginning to appear in Indian job portals. Naukri displays 109 jobs for Scrum and 296 for Agile as of today – 5th August.

About a year back some of the developer jobs started adding a line “Experience with Scrum/ XP/ TDD is an advantage”. This continues to date. Here are a few such jobs:

• An opening with http://www.truglobal.com/ for Senior .Net Developers :  The desired profile is “.Net 2.0/3.0/3.5 (WCF, REST, CLR). Strong database skills. Exposure to Agile / Scrum methodology is mandatory. Linq, ASP, VB, OOPS, XML and JQuery” Contact recruiter@truglobal.com
• Another job is from Parexel International at Hyderabad. The requirements are “4+ years of commercial development experience Educated to minimum of degree level in a science related discipline Highly proficient in English (written, verbal and comprehension) Following Must Have technical prequisties: Java 1.5 —- J2EE —- Struts 1.1+, JSTL —- XML —- XSLT HTML/XHTML —- Servlets/JSP —- JavaScript CSS —- JDBC —- SVN/CVS PL\SQL —- Oracle 10g+, —- Tomcat 5.5+, OOAD —- Formal SDLC-Waterfall/Agile —- JUnit Desirable prerequisites: Sun certification ‘ SCJP/SCJD Knowledge of Integration middleware platforms, or SOA Pharamceutial/Clinical Trials industry/domain knowledge Following technical prequisties: IntelliJ –UML –Apache Derby ANT –SQL-SQL92/ANSI –VB6 Linux –JBoss –Glassfish WebLogic –OC4J –Websphere AJAX –Web Services —Scrum Report Development –Portal Development-JSR168/286 –Workflow JIRA Development –CheckStyle/PMD/Findbugs” You can submit your resume at
  http://www.parexel.com
• Symbian Developers in Bengaluru can apply at Tata Elxsi Ltd. The exact skills required are “Debugging Tools in Symbian platform – Emulator, TRK , ODD using Carbide and Lauterbach etc,  Tracing and Profiling Tools – TRACE32 ,Profiler and analysis of profiler data, Emulator – In depth knowledge of Emulator provided by Symbian / S60 SDKs, Compiler – Various compilers supported in Symbian platform, Memory and Code dump Tools – Hook Logger and other Tools available in Symbian / S60, Core dump and crash log tools – Crash Log analysis and associated tools, Awareness of Symbian foundation tools, Static code analysis tool – Coverity Prevent Tool, Experience in Agile development – SCRUM and Knowledge on PERL.
• There are jobs in North India too. There is one available through Vanguard HR Consultancy. The job is of a Senior Software Engineer – Java. Contact Mayank@vanguardhrconsulting.com and you need to have about 06 years of Java Experience with Agile/ Scrum methodology. Specific skills required are “Extensive experience of J2EE application servers and Java web applications, Should have worked in at least 2 previous large database backed Java applications, Should have good understanding of robust database schemas and database tuning,
  Should have worked on large scale databases, Experience with JSF (Java Server Faces), Spring and Hibernate and Should have a thorough understanding of email and SMS, technology, protocols, etc.”

There are other jobs available as well. Here is one for a Senior Technical Writer from Consona. “Experience working in an agile/scrum development environment” is one of the requirements along with standard technical writer jobs.

The big guns are hiring for dedicated Scrum Coaches. As of now, Dell wants a Scrum Master for its R&D Division in Bengaluru, there are at least two product companies looking for Scrum Coaches in Pune and there is one requried at Nokia as well.

There would be others which never get listed and are filled through reference or community events as well.

However, despite these jobs being listed, I think we are still some distance away from getting more jobs in Agile and Scrum space in India – especially Scrum Masters/ Agile Coaches/ Product Owners. But the things are better and over the next one year, it should be even better.

A Successful Retrospective

Someone asked me when do you know if you just led a successful retrospective.

My first reaction was that I will have to think and come up with some metrics which optimize the complete value chain. However, I started answering sooner than later. I stopped in between, reflected and continued. On the flight back, I reflected again on what I said. I thought it made sense. Let me know what do you think?

An effective or successful retrospective should have the following characteristics “come out”:

• No one should come out of the retrospective with ill feeling or negative thoughts towards anyone.
• No one should come out of the retrospective thinking they have not been heard properly.
• No one should come out of the retrospective saying they are not a party to this decision.
• No one should feel that the real reasons or suggestions did not come out.
• The team (and PO – if he/ she was present in the meeting) should be buzzing with enthusiasm in being part of something unique.
• The team (and PO – if he/ she was present in the meeting) should come out of the retrospective with more understanding about each others roles, expectations and requirements.

I think this made a good checklist – mentally, for a Scrum Coach.

What is a Sprint Review Meeting | Iteration End Review Meeting

When a sprint or an iteration ends, the time comes to demonstrate the working software as per the stories and requirements committed originally. This is usually done in what is called a Sprint Review Meeting. During the Sprint Review Meeting,  the team demonstrates working software corresponding to project backlog items they have completed in a given sprint.

The focus of sprint review is on working software. Powerpoints, speeches, lectures and other diagrams/ presentations are not allowed. In fact overall, the meeting is kept very informal. and typically, like the Sprint Planning Meeting, last only about 01 hour per week of sprint work planned. The teams attention, selection of practices and processes is all done with regards to faster delivery of working software. For instance, since the teams focus is on delivering working software, all the arrangements [arranging room, projector, getting the environment ready etc.] are done by the Scrum Master.

Product owner, The Whole Team and Scrum Master, all attend the Sprint Review Meeting. This is done to ensure that people who have developed the software are there to answer any questions the product owner has and for product owner team [customers, stakeholders, product owners] to see what is coming up from development team. This also improves the communication in the team, with each team member further strengthening the teams understanding of the product and product owner expectations. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. The product owner team can give better feedback after seeing something working rather than on abstract IT diagrams. The teams are looking forward for the following feedback in the sprint review meeting:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

This feedback helps the team and product owner to plan better for the next sprint. The team [together] and product owner both take back points for themselves too. For instance, product owner sees if some more requirements need to be added/ edited/ deleted for next sprints and also for the team to see if they need to do better to understand or compelete more requirements.

After the sprint review is over, the date for next sprint review is announced and the team moves to Sprint Retrospective.

Sprint Planning Meeting – Introduction and Basics

If you follow iterations and sprints as part of your Agile Development Lifecycle, a key ceremony in Agile is “Sprint Planning Meeting” or also called “Iteration Planning” in other variants of Agile. Sprint in Scrum is a time period in which the team does whatever it can to develop software as per features/ requirements the team has committed to. A sprint or iteration is started with a Sprint Planning Meeting.

Lets say we are in the first sprint. The team would picks up “x”  [“x” requirements are selected through an educated guess] number of top priority requirements. A good project backlog would not only be prioritized but also estimated. The team totals the “relative estimation points” for all these requirements and that becomes the “velocity” of the team for first sprint. After discussing with the product owner, the team finalizes the requirements it would take up in the first sprint and the backlog roughly appears like this:

The team has committed to 20 points of work. As this is the first sprint, and the team has committed to the work more on an educated guess than exact science [and this would hold true for future sprints too], the team might need to take on more work [if they finish all requirements] or need to bump off some requirements [if they have taken more than they can handle]. The team will ask product owner as many questions as possible and they can think of [acceptance test cases/ test data/ UI designs etc] and give a final commitment before moving to Part II of the sprint planning session. In this session they take each requirement and break them into tasks and the team member voluneteer, discuss and self assign these tasks. A typical sprint backlog after this could look like this:

Hence, a sprint planning meeting is basically a communication channel for the team and the product owner to decide on what work the team should work on in a given sprint as well as the team doing some basic ground work on starting with a particular sprint.

It is important to emphasize here that in almost all Agile implementations, the team does not report to Product Owner. Both are independent yet important pillars of Agile/ Scrum frameworks. Hence, there are some rules of engagement which the team and product owner need to adhere to:

• The team would commit to work based on their understanding. Although, the product owner is free to ask the team if they feel they are under-committing or over-committing, there is no coercion available for the product owner. The product owner would not coerce the team into committing to more requirements than they feel comfortable with.
• The sprint planning meeting is a synchronization meeting for product owner and the team to decide what the team has to work on in the next sprint. However, the team can request product owner to be available during the sprint at regular interval [if they can sit with the team, nothing like it] to answer any questions or provide feedback – especially during the earlier sprints as the team would be spending more time understanding the domain, product, project, framework.
• The thumb rule for time to be spent on a sprint planning meeting is 2 hours for each week of sprint – 1 hour for discussion on requirements discussion and 1 hour for task breakdown.
• Finally, in Scrum at least and preferably in other flavors of Agile as well, once the team commits to the story – there would be no change: no change in development team, no change in the requirements and no swapping. However, clarifications can be provided. If the team and product owner is divided on whether it is a change or clarification, it is a change. This is done to maintain team focus on what they commit and get a rhythm going after a few sprints.

After the first sprint is over, and the team goes for second sprint planning meeting, the team has a better idea of know how many requirements they can commit to. This idea keeps becoming better and clearer with every passing sprint and sprint planning meetings would not have much of a discussion on whether the team has committed right or wrong [over or less].

A Sprint is different from an Iteration

In other frameworks under Agile, the term iteration is used to define the time period in which plan and develops an increment of functionality. So, why introduce a new term – sprint in Scrum.

The obvious answer [and correct one too] is that Scrum borrows a lot of terminology from Rugby [including the word Scrum]. A sprint in Rugby is a distance an athlete would travel from one end to another. Before an athelete or team would sprint, the team would quickly get together and plan how to go about it. During the sprint, an athlete would encounter opposition from the other team and might go ahead with the plan [if the plan still is good] or more likely alter the plan. You can anticipate but not predict the opposition. A sprint tests whether the team is a team, whether they are good or not and their ability to respond to change. It is clear to see why sprint is an appropriate terminology for Scrum. A sprint in Scrum is a time period (can be anything from 2 to 8 weeks) in which the team does whatever it can to develop software as per the features/ requirements that the Team has committed to. It is important to note that during a Sprint, the team not only iterates towards a final product solution, always improving on what they already have, but also take on some additional increments. Hence, product is developed iteratively and incrementally during a sprint. The term iteration can sometimes fail to capture the incremental part of product development during a sprint.

Management Today : What All Managers Should Know About Agile and Lean Online Teaching Class by Vikrama Dhiman

I am conducting a Webinar on Management Today, where multiple topics of interest to managers in various industries would be discussed every fortnight. These Webinars focus on Agile and Lean and will introduce these concepts to Managers. You can join and watch the class right here too.

Vodpod videos no longer available.

Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

In the previous post on “Multiple Product Owners or Not“, I analyzed if there is a case for multiple product owners. As per me, there can be grounds and case where this is a necessity. Now let’s see if we did indeed have 02 product owners, what will happen. The potential problems [I have seen these] could be:

• Product owners have power – they influence the product direction. As long as 02 or more product owners agree on the direction, it is fine. However, product owners also influence product execution [user interface, test cases, priority]. These are soft areas and different people can interpret these differently.
• Each product owner is likely to have more appreciation for their own features and their importance, than of the other product owner. If both of them feed a common development team, there would be issues of working together at some stage or the other.
• If you have product owner depending on expertise [horizontal slices than vertical slices], there will be even more potential for disaster striking soon. Let’s take an example. Something which is good from SEO perspective, might not be so great from user interface perspective. If we have 02 product owners, one for SEO and one for user interface, major conflicts will arise.
• Having a whole lot of people influence product direction can mean paralysis in decision making, where almost the bare minimum everyone can agree on, only gets done and anything exciting and challenging, will never even be attempted.

There are some things one can try, to make multiple product owners work together. Let’s look at some possible solutions:

• One way to work around this is to have all the members of the team as stakeholders, but have a Chief Product Owner to have the final responsibility of prioritization. Hence, depending on the size and nature of your product, one might have group of people responsible for grooming the product backlog [design, SEO, user acquisition, interface, development, marketing] but only one person should be responsible for overall prioritization as well as decision making in case of conflict. The problem in this case is to identify such a person. Typically, such a person would be someone with great knowledge about the product, marketing and strategic objectives. This is the typical approach and this takes along specialists in various domains together. Although, this is against the idea of generalists not specialists, it is needed. I personally believe specialists have their place and very important one too. I have benefited as a Product Manager from people advising me on aspects I will overlook or most likely not even know. Specialists give me insight from marketing perspective – Internet Marketing (paid), Internet Marketing (organic), Offline Marketing Channels, User Behavior … one which [A] I won’t ever get time to analyze in detail or [B] would need enormous training to even get started.
• Another approach is to divide the product in multiple sub-products. The Chief Product Owner can divide work to other Product Owners depending on their expertise, experience and importance of the features. This is commonly called feature teams. Organizations and products which spend time on this, reap benefits. We are getting started on this and this is streamlining our processes. There will always be areas where the Chief Product Owner would step in, but mostly delegation and scalability of product owner roles is supported through this model.