Archive for the SCRUM Category

Manager 2.0 – Managing an Agile Team and Enterprise

Posted in Agile, People Management, SCRUM with tags , , , , , , on February 4, 2009 by vikramadhiman

If we use the SCO Model of Management to classify a variety of tasks are performed by managers in IT and other organizations, we can typically divide these tasks in three categories : Strategic, Coordinative and Operational. Strategic actions focus on long term. It is designed to achieve a particular goal through careful evaluation of current situation, future multiple scenarios and alternative choices for the same. Strategic activities and tasks are about defining a strategy [current and future scenario and how best to get there]. Strategic activities and tasks also rest on continually monitoring and adapting. The strategists typically monitor the market situation and business metrics, continusouly aligning their organizations as per market environment. They answer questions like what the organization should focus on, how they should do what they do and how to become more effective and gain competitive advantage. Coordinative tasks are mostly targeted at one specific segment of enterprise and its relation with other segments of an enterprise [and not with those segments of enterprise they are not related to]. Hence, they are based on actions used by a small unit to implement a specific objective. Hence, almost all coordinative tasks are about coordination. The focus is on optimal utilization, coordination and good processes. Operations or processes are a set of well defined, finite tasks. While there can be defined, finite tasks to do strategic and coordinative tasks as well – the main difference between strategic/ coordinative and operational tasks is repeatability. Most operational tasks are repeatable. It is also easy to come up with quantifiable measures to evaluate the success of operation, after a period of time.

Let’s take an example. “User Experience” is an important aspect of any business. As a strategist, the focus is on what are the challenges in designing good user experience, coming up with mechanisms to define who the target audience is, what is the competition and what is an acceptable level of user experience. A coordinative task in the meanwhile could be to have core product line managers focus on standards, coordinating design and HTML activities, analyzing with business analysts, process flows, coming up with design glossary etc. Operational tasks are specific activities like doing actual designs, making HTML pages, testing HTML pages etc. In most organizations, this is how work gets done. Strategy is defined by senior most managers and most managers work in the coordinative space with employees working in operational space. Agile changes this mindset slightly.

The default assumption  by providing strategic power at the top is that flow of control, information, direction is from top to bottom and some people are more equipped to handle some tasks [based on experience, stake in company etc.]. However, an effective strategy would incorporate flow from bottom to top as well. This is because this allows people to get feedback right from the people who are in touch with the market / are doing something themselves. A host of measures have been implemented by various companies for this. Formal mechanisms like feedback surveys are one way of doing this. However, making it formal, periodic makes it a process rather than actually yield results. Strategists need to know what are they missing [most often they will miss communicating with coordinators and operators clearly enough]. Also, the challenge is to understand where the operators knowledge can be better utilized and in current times, this can be anywhere. Hence, more than just jargons of flat organization, everyone is equal – it should be practiced. Management should explain business objectives, directions – get questioned by coordinators and operators on why this business direction and why not something else. After all doubts are clarified, operators will go about their job with more clarity, enthusiasm and direction. Hence, individual units to align them with goals and objectives of organization/ project “as they want to be”. One way of doing this is rather than focusing much on “how to do something”, a broad framework to be provided to the team and they figure out how to do this. In short, it changes the hierarchy.

Let’s look at some of the tasks that managers typically perform :

  1. Task Breakdown
  2. Task Assignment
  3. Task Tracking
  4. Client Communication
  5. Providing feedback to people
  6. Recommending Appraisals
  7. Interviews
  8. Team Building
  9. Trainings
  10. Strategy Planning
  11. Project Reports
  12. Attrition Control
  13. Value Creation
  14. Project Cost Tracking

There can be many more such tasks. Let’s evaluate if managers should continue doing these tasks in the Agile world as well or not. [1], [2] and [3] would not fit in ideally. [4] – [14] would undergo a significant change. For instance, as part of recommending appraisals, the managers would be involved only as one part. A 360-degree feedback along with linked appraisal or same appraisal for whole team based on collective effort are some approaches which can be used. These approaches are not unique to Agile but work well to keep the team at the heart. Similarly, team building happens by creating a spirit in each member to see best interest of the team as well as project and orient themselves towards it without being asked to do. Similarly, value creation is through building people and building systems that make the team hyper productive.  This is definitely tough to do.

The role of Manager 2.0 is to ensure that everyone through out the value chain is involved in all the aspects – strategy, coordinative and operational. This is easier said than done and requires creation of a democratic work space and choice driven coordination up and down the value chain. Some of the day to day transactional tasks like task reporting, task division etc. are no longer done by the managers [you don't want an expensive clerk]. Some others like providing feedback, performance appraisals, salary appraisals, recruiting, firing are now done slightly differently. In addition, the managers take on more tasks. Basically, they stop being a nanny and move towards servant leadership. Let us revisit the SCO model and see how strategic, coordinative and operational activities are carried out by the The Team, Scrum Master and Product Owner.

The Team :

  • Strategic : The team makes decisions regarding which practices it would use, how much work it can commit to during  a sprint. It also identifies obstacles and opportunities for growth that would help technical architecture of the practice.
  • Coordinative : The team is self organizing. They use variety of tools like daily stand up, sprint retrospectives and sprint backlog for internal coordination and others like sprint planning, product backlog and sprint review with the marketing leadership/ product owner.
  • Operational : This is left for the team to identify for themselves. A number of XP Practices like refactoring, test driven development, shared code etc. However, the choice is left for the team.

Scrum Master or Process Coach:

  • Strategic : Scrum Master is in charge of the Scrum Process/ Agile Framework. She guides, checks and consults on the teams use of Agile and Scrum, She helps the team identify obstacles and remove them. In short, she is in charge of the productivity of the team.
  • Coordinative : Scrum Master or Process Coach can sometimes work as a coordinative mechanism with other departments. Intra-team coordination is generally left to the team unless two team members specifically ask Scrum Master or Process Coach to intervene. In some situations, some tasks in this domain require expertise or responsibility that goes beyond the spirit of Scrum Master. These can be things like interviewing new people for the job, giving individual performance feedback, recommending salary appraisals, being responsible for attrition and individual growth etc. Typically, organizations employ a Manager. A Manager can sometimes work as Scrum Master + other tasks or do only “the tasks” while Scrum Master goes about monitoring the Scrum Process.
  • Operational : This is not defined. Scrum Master or Process Coach can use tools at their disposal like observance, notes etc. to do their work. As most of their work is thought process, speaking and engagement – defining exact tools is slightly wishful.

Product Owner:

  • Strategic : The success of the product is product owners responsibility. She is responsible for gathering customer requirements, prioritizing them, setting the release schedule, getting the right product built. In short, the strategic success plan has to come from the product owner. She can sometimes as a part of this, discuss with the team, the skills and requirements for this success.
  • Coordinative : The product owner engages with the team at sprint planning, sprint review and by drafting a project backlog. She is also available through out the sprint for any questions and discussions. The team works at any given time as per the priority defined by the product owner.
  • Operational : The operational tasks of Product Owner involve gathering requirements, gathering market feedback, prioritizing requirements, communication and tracking product success.

Manager 2.0 :

  • Strategic : Focuses on Value Creation. We find focus on creating processes as per Lean principles, a great starting point. Hence, a Manager 2.0 would focus on:
    • Eliminating waste
    • Building quality in processes and systems – making systems mistake proof
    • Creating a culture of respect for all people
    • Focus on the value for the end customer
    • Optimizing the whole
      • We will expand on this in the posts on Lean Engineering Principles.
  • Coordinative : A Manager can take on the responsibility for arranging resources, people, interviewing, feedback, appraisals – all the tasks which if done by Process Coach/ Scrum Master would actually hamper their ability to inspire trust. In a way, a manager’s job becomes more difficult than a Process Coach/ Scrum Master. They have to not only do some tasks which require certain authority and reporting, but also keep the environment trust worthy and open.
  • Operational : This does not differ much from operational tasks that they do anyways. However, significant percentage of their tasks are thinking and communication based. Hence, appropriate choice of tools is more important.

Overall, Manager 2.0 would be responsible for creation of a value based people driven culture. They also would be responsible for scaling Agile and helping the team identify appropriate practices. There main role is best summed up this way “They create a self organizing team and empower it so much, that they themselves are no longer needed. Hence, its more of a self burning role.

Test Driven Development : Introduction by Jeff Langr

Posted in Agile, SCRUM, WiZiQ with tags , , , , , , , , on January 28, 2009 by vikramadhiman

Jeff Langr, is conducting a Free Online Webinar on Test Driven Development : An Introduction on WiZiQ. It is completely free to attend. All you need to do is sign up for free with WiZiQ.

I for one had been looking at such a webinar/ online training for a while now and it is really good to see Jeff conducting this webinar.

Ideal Iteration Length, Sprint Length, How Long should be a Sprint or Iteration

Posted in Agile, Release Planning, SCRUM with tags , , , , , , , , on January 11, 2009 by vikramadhiman

New teams struggling with Scrum or Agile adoption more than often struggle with their Sprint or Iteration Length. [Whether or not a Sprint or Iteration is a good thing or needed for Agility is a debatable topic in itself though]. Most of the teams pick up iterations or sprints month or even two months long. Then their idea of Iteration is moulded in Waterfall Phases [this is a Design Sprint, this is a Coding Sprint, this is a QA sprint and this is a Release Sprint] – this is for another day. When deciding on the length of a sprint or iteration, many factors need to be considered:

  • Administrative Overhead : Each iteration needs a planning meeting/ game to kick start the iteration. Each iteration would also need a closing/ review meeting. And there will also be a retrospective at the end of iteration. Although one can say that the size of these meetings [minutes consumed] would depend on the length of sprint, so as long as these meetings comprise say just 10% [you can come up with your number] of overall time available for a sprint/ iteration, it should be fine. I personally think this reasoning is fine. If meetings are taking longer, then there are generally Process Smells – Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
  • Feedback/ Flexibility : Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction – more chances of canceling the sprint and more chances of things being obsolete [competitive advantage erosion].
  • How good is the marketing team : If the marketing team is good [Product Owner is good], then he/ she will break the stories or tasks small enough to keep sprint/ iteration length small. He/ she would know the worth and priority for each story or task and help the team pick up most important stuff – minimizing stuff thats not needed – helping the team become Agile.
  • How Fast can the team move : This is generally the most important factor in deciding a sprint length. Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves. If they had confidence in themselves [they were doing refactoring, TDD, shared code or just were good group of people together].
There was a certain slant for a smaller iteration length in the post. This is because:
  • Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
  • Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
  • Shorter sprints or iterations force continuous evaluation regularly and quickly.
  • Shorter sprints or iterations also allows the team to establish
    an empirical velocity very quickly.
Some people and trainers say that when teams are new to Agile/ Scrum, they could start with 2 week sprint. I generally advise against this. I would rather have them do 1 week sprints with lesser stories – allows them to learn quicker and faster. However, important point to note is that each team is unique and each product is unique as well – hence, there might be cases for 2 weeks as well as 2 months sprints. I haven’t come across any so far though.

Lets Talk Agile : Excellent Presentation from Slideshare

Posted in Agile, SCRUM with tags , , , , , on December 31, 2008 by vikramadhiman

I happened to chance upon a spectacular and to-the point introduction from Denis Caron. I thought it was direct [although sometimes it just was probably too much rather than just enough] and very exciting. It touched upon the normal subjects like agile not being a silver bullet/ magic wand but also that it is not a process or methodology. Slide 24 explained the main essence of Agile pretty well:

  1. Time-box everything and stick to it!
  2. Anticipate change in everything you do.
  3. Don’t build monuments, keep it light and malleable.

And the market compulsions have been explained succinctly too : Change happens fast, our competitors will not wait for us while we get ready! and Learning faster than our competitor is our only sustainable competitive advantage

Lean Thinking – An Introduction

Posted in Agile, SCRUM, WiZiQ with tags , , , , , , , on December 21, 2008 by vikramadhiman

I have done an online webinar on Lean Thinking Introduction for Beginners and Dummies on WiZiQ. This presentation has been the basis for the same – I have compiled this from various sources and keep improving it when I find an example from real world experience or web, that I feel should go here. I hope you find this a useful resource for Lean Thinking Introduction.

Lean Thinking Introduction by Vikrama Dhiman

Scrum Exposes Bad Processes and Obstacles

Posted in Agile, Retrospectives, SCRUM with tags , , , , , , , on December 19, 2008 by vikramadhiman

In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo's implementation of Scrum].

Often, as the end of a sprint, the team comes back and says things like

  • Its more stressful in Agile
  • Things are worse than before
  • Agile does not work
  • We were better off before

If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:

  1. Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
  2. Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
  3. Compile the score and let there be pin drop silence in the retrospective.
  4. The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
  5. The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.

It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.

Agile Retrospectives Start Stop Continue

Posted in Agile, Retrospectives, SCRUM with tags , , , , on December 15, 2008 by vikramadhiman

Revisiting the discussion on agile retrospectives, it is recognized by some as the single most effective practice/ ceremony of Agile. This could be because this exercise:

  1. Brings the team together
  2. The team inspects what it has been doing
  3. The team tries to adapt for better results

On a score of 04 based on Agile Manifesto, Agile Retrospectives would score a 02. They are about individuals and interactions and help the team respond to change. In addition, Agile Retrospectives help the team focus on 02 other principles of the Agile Manifesto : Customer Collaboration and Working Software.

There are various approaches in conducting Agile Retrospectives. One of the most common approach that is advocated by many coaches is “Start, Stop, Continue”. A very simple approach, this type of retrospective is usually conducted as follows:

1. All team members make 3 lists – what is working well and they should Continue doing, what is not working well and should be stopped, and what is something that can be explored/ Started.

2. One-by-one everyone adds their points to a central whiteboard/ list. They can do a plus 1 if what they want is already on the list.

3. After everyone has completed this, the team picks up the items with most “plus 1″.

4. They commit to “some” or “all” items in the 03 lists – Start List, Stop List, Continue List.

5. In the next retrospective, they go back to this list and evaluate how they have done [this can be done in a variety of ways too - everyone votes on whether they were successful in implementing something or not and after this a new Start, Stop, Continue List is drawn].

6. Some people like to keep it mechanical – vote and decide. Others like a lot of brainstorming, discussions and debates. Its useful to have debate on what you are planning to do. The only downside of debates in retrospectives is that more powerful or vociferous attendees may overpower others. Hence, the Scrum Master has to be really good.

This is a relatively simple approach and helps the team inspect and adapt continuously.

P.S. If you are in India, and haven’t taken this “Are we Really Agile Survey” then, I recommend you do so right away : [it will only take a couple of minutes and is straight forward multiple choice survey].

Agile Certification | Scrum Certification – Good or Bad

Posted in CSM Course, SCRUM with tags , , on December 8, 2008 by vikramadhiman

There have been murmurs in the past about certifications in the Agile community, not all of them good and almost all of them for Certified Scrum Master. Here are some blogs and articles I have read. Ian Culling has a well read ” I am a Certified ScrumMaster – BFD“, “Agile [Scrum] Certification Debate“, “Scrum Certification Test” and “Scrum Master Certification – What’s it Worth?” Some of the common criticism about CSM is:

  • Certified Scrum Master is not good enough guarantee that those who are certified are good to be a Scrum Master. Heck, its not even a guarantee that you know Scrum, forget become a Scrum Master.
  • There is no test. It only certifies that you attended a 2-day course, which is not enough.
  • There are no pre-requisites – no experience criteria, no reading criteria etc.
  • There are no follow ups suggested other than [possibly very mean] renew your membership of Scrum Alliance every year.
  • There is not enough transparency in the CSP [Certified Scrum Practitioner] and CST [Certified Scrum Trainer] certifications.
  • There can be people who don’t have a certification, that can be very good.
  • Scrum or Agile is not something you can measure. You can never check individual performance in a team based approach like Scrum or Agile.

All of these are valid arguments. It is also interesting that not many people have issue with CSP. Its CST and CSM that gets people worked up. I guess its the nomenclature. If they renamed Certified Scrum Master as Certified Scrum Beginner or Scrum Alliance Member or Certified Scrum Master – Level 1, no one would have any issue [other than probably people who take this certification only for title]. You can also counter most of arguments above by saying that all IT professional certifications are crap [someone passed MCSD, but could not answer D of Design or someone is RHCE, but knows nothing about ports].

I personally do not have anything against CSM or CSP. I was a member of Scrum Alliance for a year and then my membership lapsed in September this year. I assume I am no longer a CSM now. Its not that it affects me in any way. I think writing this blog, being active on various Agile and Scrum groups and also networking well, are more important. But that’s a personal choice. I might just renew my membership with Scrum Alliance soon. Rather than blame Scrum Alliance, I would ask people who have an issue with CSM or “some secret Agenda of SA” to let the world know what CSM really is and whether people should value CSM or CSP. I for instance, would not recruit someone or interview someone simply because he/ she is CSM. But if he/ she is CSP or CST, my view will change.

Would a stricter examination or other things help? Probably yes. I am not for experience part [you should have certain experience before you are allowed to take CSM for instance] here – there is no guarantee that 4 year experienced employee is better than 2 year one or even a 0 year one. Similarly, follow up actions after the certification can be difficult to track – will you track blog posts or something else? I think for now CSP is good. And then, may be Scrum Alliance will reword CSM to something which explains this better.

Scrum Session Series : Introduction to Agile Software Development using Scrum by Vikrama Dhiman

Posted in Public Speaking, SCRUM, WiZiQ with tags , , , , on November 28, 2008 by vikramadhiman

Live Free Online Public Training Session on Scrum Session Series : Introduction to Agile Software Development using Scrum by Vikrama Dhiman

Take away’s from this session:

  • Understand what is Agile Software Development
  • Origins of Scrum
  • What is Scrum?
  • Who is using Scrum
  • What can’t be solved by Scrum
  • A brief overview of Scrum Framework

Scrum not equal to Agile | Scrum is not Agile

Posted in SCRUM with tags , , on November 26, 2008 by vikramadhiman

I have seen many a people say that Scrum is not Agile in strictest sense. Why? Because it forces down processes on people rather than have people fix the process. In fact in much of the CSM classes, you are told this is something you can tweak and this is something you can not. For instance, you do need a Sprint Planning, you need to do a Sprint Review and Retrospective and a Daily Scrum, have a Product Owner, Scrum Master and a Team. I guess you can omit the last part because you will need it anyways. You can not choose not to have a Scrum Master or a Product Owner or worse not do Daily Scrum. What if a team does not want to? Well the simple answer seems to be, you don’t have to do Scrum by the book. It pays to do it by the book till you get used to it and once you get used to it you can start questioning the wisdom of the roles and practices. There is nothing, that says you can not question the wisdom at the start itself – however, if you question after trying something out a hundred percent, you might be able to question better [or at least that's what I think and I can be wrong on this].

My take on this and something I tell the teams I deliver sessions to is : Agile is like a religion. You can be religious without following “a” religion [like Hinduism or Christianity]. But following Hinduism or Christianity can be a good starting point to be religious for some [but not all]. Further, you can be Hindu and Christian at the same time [many Hindus study in Convent Schools and celebrate Christmas]. In addition, you can never be more Hindu or Christian than another Hindu or Christian. Both of you are at your own levels. Similarly, Scrum can be a very good starting point and you can mix it with some of XP or less of XP. Also, unlike rabid Scrummists, I also suggest that you can never be doing more Scrum or less Scrum than others. Tests like the Nokia Test for Scrum are a good reference and starting point but the team should be able to come up with their own tests and revise it often.

Just like having fanatics in a religion does not make a religion bad, having a group of aggressive consultants market Agile, does not mean Agile in itself is bad. Similarly, you often hear : “Religion is always private and something that you share with God, you don’t want others to preach it down.” The problem with this viewpoint is that it is your viewpoint. You might not want priests to help you connect with the God, but others might. Similarly, much of Agile might be common sense but getting this common sense across might need an external consultant. This is what blog posts like The Agile Disease, Scrum fails to come to grips with Human Psycology and Technology is already Extreme get wrong.

I always tell whom ever I talk to Agile about, Agile is not a destination, its a journey. Take Scrum, XP, and everything else as milestones that help you savor and experience different aspects of Agile. Eventually your own journey could help you define and discover, what you think they [Agile, Scrum, XP or <insert your framework name here>] should contain.


Get every new post delivered to your Inbox.