Archive for the Change Category

Team Leads or Project Managers as Scrum Masters

Posted in Agile, Change, Project Backlog, SCRUM with tags , , , on July 22, 2010 by vikramadhiman

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.

When Should You Implement Scrum or Agile?

Posted in Agile, Change with tags , , , , , on August 19, 2009 by vikramadhiman

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

  1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
  2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
  3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

  1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
  2. The cost of a single bug is very high.
  3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Project Manager to Agile Coach – The Journey

Posted in Agile, Change, People Management with tags , , , , , on November 28, 2008 by vikramadhiman

One of my favorite YouTube videos about transition the project managers have to make from being a project manager to Agile Coach is from Lyassa. Here are the videos if you have not seen them already:

Lyssa, compiles some excellent points from general beliefs and principles that most Agile Coaches adhere to, primarily:

  • Many things that contributed to my success as a PM are exactly the same things that spell doom for an Agile team – especially being the center of everything on the project : from communication to task allocation to tracking to being responsible for the outcomes of the team
  • I need to know how to foster collaboration by bringing on my skills as a good facilitator
  • Servant Leadership – Not only know but practice it religiously
  • Trust on the teams – Without this, you wont get a 10% of performance from a team

I will try and gorge on other material on the Internet for the same as this is an important topic to discuss.

A New Job

Posted in Change, WiZiQ with tags , on June 23, 2008 by vikramadhiman

Its been slow on this blogs front for a while now [2 months now]. This is because, I have recently joined a growing Internet Product Company, as a Product Manager. This is a great opportunity for me. As a Product Manager, I would be the marketing teams interface with development team. I would have a team of marketing people working with me and I will work with them to identify the customers real needs. We will develop as per the priorities in the market and this is a real exercise in me to become a product owner. Already I am grappling with issues like prioritizing the tasks – identifying the best process to complete the tasks in a weeks time [our sprint time] and defining the releases. I am also working with Internet Marketing team, Marketing team and Support team. An all rounded exposure would provide me a great experience to becomes a Gen-Next Product Manager.

Managers in Agile

Posted in Agile, Change with tags , on February 1, 2008 by vikramadhiman
One of the challenge and opportunity that transition to Agile presents for most organizations, is to redefine how we manage things [and we saw in last post – how difficult it can be] and importantly the role of a manager.
Well, below is a general outline of some of the things managers do in their current roles:
  • Do code reviews
  • Define tasks
  • Assign tasks
  • Track tasks
  • Firefight
  • Make MS Project Plan
  • Make Excel Reports
  • Talk to the customers
  • Give feedback to team members
  • Recommend appraisal of team members
  • Promote team members
  • Give presentations
  • Train people
  • Write case studies
  • Write white papers
  • Work with other teams
  • Provide technical leadership
  • Provide process leadership
  • Provider marketing leadership
  • Do HTML coding or other housekeeping work
  • Keep customer happy
  • Read about technology and trends
  • Make usage projections
  • Improve company bottomline
  • Recommend engineering practices
  • Control attrition
  • Interview and hire
  • Provide status updates
There can be more depending on which organization do you work with. All that is needed is to come up with all the tasks that you do and cross out ones you should not do in Agile. Assigning and tracking tasks are obvious ones to go. There are many above that can be crossed. After this, investigate if any more things should be added to the mix. Thats it – you have a great new JD for a Manager. CMMi – here we come 🙂

We do not know how to …

Posted in Agile, Change with tags , on January 21, 2008 by vikramadhiman
A lot of people come to me these days and ask, ever since we started doing Agile, things have gone from bad to worse. Some of the things that go wrong [according to them] are:
  • We do not know how to bill – the customer wants a fixed price while we can’t give it in Agile
  • We do not know how to hire – there are so many things we need to look for more, we can’t seem to find enough people
  • We do not know how to train – we need to coach people on things like responsibility, duties and collaboration
  • We do not know how to measure – how can you measure without knowing what everyone else did
  • We do not know how to manage requirements – they just keeping all the time and we do not know how to keep architecture scalable for that
  • We do not know how to manage – Agile just throws so many things in diverse directions and we do not know how to go about things
My first response to this is “Ok! At least you know all this and got so far”. Invariably I find out that the reason they are unable to manage the above is because they are able to somehow manage to do the impossible – reinvent the wheel on Scrum and XP. Probably its the comfort of familiar rather than uncomfort of unfamiliar, although that may turn out more comfortable. Needless to say there are many solutions available for the above. We will try and see some of them in the future posts.

Change is Difficult

Posted in Change, Coaching at Net Solutions with tags , , on January 27, 2007 by vikramadhiman

The managers second session on Jan 20, 2007 was very interesting. It was something that was long time coming. The CEO had some other engagement, so could not make it on time. Hence, it was the managers and the Agile proponents. The topic was also suitably – Management Roles in SCRUM: Product Owner and SCRUM Master. I had to orient the course in terms of “what role would SCRUM Masters play in their teams” rather than as a critique of current project management style. Through out the session I emphasized how SCRUM Master is the natural progression for all project managers. However, it did not seem to have cut any ice. The managers are reported to have remarked : “you don’t need us any longer”, “our developers are coming up with strange interpretations of SCRUM”, “I am having difficulty controlling developers” etc. There have been two cases where managers have actually broken down. On another occasion people have been shouted on. Our effort seems to be stuck. At one point it seemed like I would go ahead with teams which are responding and leave the others. And then we thought – if I do that, whats the difference between current management style and Agile thinking I am propogating. The challenge is to win the trust of all. It is very difficult but then change is difficult.

I chanced upon the following excerpt from “CIO Playbook for Adopting SCRUM”, apparently co-authored by Ken Schwaber:

Change is hard work and there is no way around the hard work. Organizations implementing Scrum sometimes misidentify the hard work as someone’s fault, something that can be made to go away if the group at fault would just “clean up their act”. This type of organizational blame can kill a Scrum implementation, and with it the organization’s ability to build better software. When something is painful, when something goes wrong, recognize this is just part of the change that is occurring; it is an opportunity for everyone to get together to figure out how to solve the problem, together.

Scrum cannot be planned for and implemented with checklists, procedures, and forms. Scrum is just a simple framework that will identify everything in an organization that gets in the way of optimally building software. The work to manage and remove these impediments represents the difficult part of implementing Scrum, and it is different for every organization, since every organization is different.

Nobody likes pain and difficulty; many of the impediments are so inherent to an organization’s way of thinking and operating that they are very difficult to remove. No amount of planning up front will mitigate this difficulty; it will only help alert everyone to the hard work that must be done to become a world-class competitor. Scrum requires that senior management be vitally involved in impediment triage and removal, and therefore requires that the CIO adopting Scrum become the leading agent for change.

In this way, the CIO engages in a process of continued organizational improvement, all aimed at increasing the productivity and quality of the software teams. It’s not easy, and the leadership the CIO provides will be a critical factor in success, as the following note from Ken Schwaber to a CEO illustrates:

From: Ken Schwaber
To: XXX XXXXX, CEO for XXXXXXX Corporation
“On one hand, Scrum offers some very attractive possibilities – increased productivity, a better working environment, increased competitiveness, and a higher quality product. On the other hand, it is hard to implement. The amount of change engendered by a Scrum implementation is significant and difficult.

Even though the change is difficult for the developers and customers (product owners), they have immediate payback through increased job satisfaction. This helps them through times of stress and anxiety. Middle management, however, is stressed without immediate reward. They are asked to help transition an organization from traditional approaches to leaner approaches without a clear vision of a personal end point … what will I do and where will I fit into the new organization. This question is particularly difficult and fraught with danger since middle management will be fashioning the new organization. The potential for conflict and politics is daunting.

My experience with top-down, enterprise implementations of Scrum has led me to believe that the differentiator between success and failure is you. Your ability to vision the future and help communicate it to your management, your ability to patiently guide them through the change, and your ability to assure your middle management of their value and form them into a team will differentiate your ability to absorb the change and realize the benefits, or not.”

Although I am not the CIO of the organization and nor do I wield as much power – yet it would be worthwhile absorbing some of the above. Implementing this is a personal challenge itself. But then as I told the managers:

“SCRUM Management requires a much different level of intellect and emotional connect than traditional management.”