Archive for SCRUM

One Product Owner Only or More Than One?

Posted in Agile, Collaboration, Project Backlog with tags , , , , on February 21, 2009 by vikramadhiman

Once every few months, debate on “Whether there is a case for multiple product owners” comes back in Scrum and Agile Community. Most often, the response by Scrum Community is – No. There should be only one product owner and there CAN NOT BE more than one product owner. There are some [like me], who suggest that after the very first releases out, the product becomes too big and complex and multiple directions emerge and one person does not have full knowledge or expertise or even time to be able to do the job of a product owner effectively.

Let’s start by looking at the role of a product owner. Product owner is the main decision maker on behalf of the stakeholders, users, customers and clients. Product owner decides what is to be built and when. Product owner is not the only contact but most likely the primary contact for the team. If the team has only 01 product owner, it should theoretically move faster. One person would make faster decisions and team will get used to working with one person after a few sprints, fostering increased collaboration and more agility. This works fine if the product owner is available and qualified to make these decisions. However, this might not always be the case. As the product grows, there would be multiple directions, sub-products and large development teams. One product owner might just not be qualified or even available to take the product further. Hence, if 01 product owner is the bottleneck [does not have time, does not have competence], adding a product owner might be a good or only option. This is not always smooth and not without its problems. However, this is the only option available. And like scaling development teams and Scrum Master role, Product Owner Role also needs to be scaled.

The main argument against why there should not be multiple product owners, is that in Scrum, Product Owner is the single wringable neck. So, once you have more product owners, you won’t know whose neck(s) to wring? This according to me is a no starter argument in the first place. I have never understood the concept of single wringable neck at all. How can one person be so powerful as to be responsible for the overall success of the product? Product Owner trusts various people to give the right input. Product Owners listen to various people who give their own input and then prioritize features. Success or failure of these features [some of which can take time to reflect], are dependent on the advice. It is a collaborative, snyergestic relationship between domain heads and product owner. Both are in it together, and not separate. Further, the idea of single wringable neck goes against the ideals of Agile as well. What is the use of wringing someone’s neck after product fails? Why not start with “Everyone did everything in their power to make the product successful” thinking to the product owner as well? And, most importantly, can “we need 01 single wringable neck” potentially overpower a solution that can work [and works] of scaling the product owner role further?

In my next post : Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

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.

Scrum Training at Mobile Manufacturer and Software Major in Bangalore

Posted in Course Assistance with tags , , , , on January 27, 2009 by vikramadhiman

Another 01 day training session at Bangalore. This one is at a mobile manufacturer and software major situated on Maratahalli Road.

The 01 day training focuses on Scrum – Fundamentals of Scrum. I have envisaged covering the following modules:

Background and Introduction to Scrum

Introducing Scrum Framework : Ceremonies

Introducing Scrum Framework : Roles

Introducing Scrum Framework : Artifacts

Rolling out Scrum

As far as feedback from fellow presenters is concerned, they say the company uses Scrum and “knowledge” of Scrum is high. Implementation level pangs exist primarily from role of Scrum Master, Performance Evaluation and Product Management. I will try and address them in this session. I hope people join the training session to learn rather than just for the certificate.

Scrum and Agile in a Fixed Price Project Environment

Posted in Agile, Business Value, Contracts with tags , , , , , , on January 16, 2009 by vikramadhiman

A lot of people have been writing that they like what they read and hear about Agile and Scrum. They then give presentations to their senior management about Agile and they seem to like what they read and hear too. However, the biggest stumbling block is fixed-cost environment. This is primarily true for almost all services companies [and these outnumber new product development companies by a margin - my guess]. An amount of funding is bid for at the start of a project. The problem is how to come to a number for these bids.

Here are a couple of approaches to tackle this [which work for me]:

Approach One : Try using Scrum as a management tool without changing your current bidding structure. Once the team has experience with Scrum, then you should have some metrics collected. The team(s) should have an idea about their velocity and more people involved at bidding stage [think of planning for a fixed-cost project as any other Scrum planning session], the team should be able to give a good estimate for the first 2-3 sprints, even for the full
project if that is what’s required. More importantly, they will ask the Product Owner/ Manager/ Client very pertinent and relevant question about priority and testing to evaluate the story. The fixed costs are based on the knowledge you have at time of planning, so you can post these on the contract too. As time goes by, and your sprints commence, the requirements will change and so will your estimates. You can negotiate them using the existing negotiation framework. However, at the end of your budget [fixed price], the product should have these functions implemented that she wanted the most.

Approach Two : Try bidding low, not in price but what are you able to give to the customer as well as be aggressive on the date when you can launch the product. Most customers and product owners/ managers would give their right leg for the same. Try it on a low risk project/ low risk client [one where you have an option of trying]. If you are bidding low, chances of getting the bid right are higher [again that's just my guess]

You may also like to read Myths about Agile Software Development and Scrum, Agile Collaboration Schemas, Agile Contracts, Contracts in Agile, Business View, Learning and Evolution and Agile Estimating.

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.

Individual Performance in Agile Team, Assessment and Individual Burndown Charts

Posted in Agile, Agile Metrics, People Management with tags , , , , , , , on January 7, 2009 by vikramadhiman

Every few months, on almost any discussion thread on Agile, the issue of assessing individual performance, individual assessment, checking how each person is performing, how to identify whether someone is performing well or bad, how to do appraisals etc. Most people respond by saying that at the heart of these discussions is “desire to control as well as fear of not being able to channelize”.  Some of the posts where authors have taken this viewpoint are Review Process for Agile Team Member, Aboloshing Performance Appraisals and Performance Management Trouble. I will not take this viewpoint in this post. I will tackle the issue from the standpoint that yes there is a problem – there is an erring employee and now you need to take action.

One of the key things with this premise [there is an erring employee] is to be factually correct as well as appear to be correct. The first is most often dealt with by clearing to an appraisee the expectations from someone and sometimes this being done in the writing, along with effective methods of measuring the performance as per these expectations. The problem in this generally is “the communication”. Managers are generally myopic in what the expectations from people are – they will lay down expectations which result in a person aiming for personal brownie points rather than help the team grow or becomes just too much of a good samaritan, almost not growing himself/ herself. The challenge in an Agile [or even any team] is to achieve this balance. Hence, your expectations would be a mix of individual as well as team behavior. Once this is achieved, the next challenge is to get the team member to agree to your expectations. There is always “Either you agree or you go strategy” – you can leverage this only if you feel you have drafted fair expectations and the employee is lowering standards unreasonably. Once the buy in is there are your expectations are clear and accepted, the bigger challenge awaits – collecting data. The best data is the one you collect automatically, and not one which others enter in spreadsheets. This truly becomes a challenge as machine collected data is easy to fake and often throws a challenge for users to fudge and overcome. In this scenario, the next best bet is to use Jeff Sutherlands technique. Basically, tweak the 360 degree feedback for something better and meaningful.

If you can get both the above points going, it would be transparent as clean air on who is performing and who is not or better still who is an asset and who is not. Now you have two options : firing or improvement. I personally try the latter. This means you have to really get to the heart of the situation on why someone is performing bad [what parameters the score is bad on leads you to this further analysis]. Once someone is beyond repair, either they would have got the hint already or you then just need to do the needful.

All things said and done, I believe and my own experience suggests that there is a better technique to manage individual and team performance and I call it SCO technique : Small Team, Close Team, Open Team.

  • Small Team : Not more than 9 people, manager but does not manage 99% of time
  • Close Team : The team generally works free of interference from outside environment
  • Open Team : You can sense when there is a problem and discuss it openly

Managers know better about people in this case and you can have a heart to heart talk and decide future course of action in this scenario. But this is not without its problems : people can sometimes become so close that they can not make the distinction between their relation and their work. Its funny how this is also the crux of Bhagavad Gita – you should know what is your karma and do it, not allowing anything you long for or love to interfere. If the team and particularly the manager is able to follow this, this is a good model. My guess is most people are not strong enough or evolved enough to follow this – hence, they keep a distance, not let go and hide behind setting expectations and measuring them.

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

Is Agile Software Development Equal to Cowboy Coding?

Posted in Agile with tags , , , , , , on December 30, 2008 by vikramadhiman

This is an often asked question. Almost 2-3 people ask me this in each session I conduct – online or face to face. Let’s first look at what is this Cowboy Coding. Cowboy coding is the absence of a defined method : team members do whatever they feel is right. Cowboy Coding is a term used to describe software development where the developers have autonomy over the development process. This includes control of the project’s schedule, algorithms, tools, and coding style.

Anyone who has read even the Agile Manifesto will know that this is not true.

[A] Agile software development re-evaluates plans frequently, emphasizes face-to-face communication, and values working software over use of documents. However, most Agile teams do follow defined (and often very disciplined and rigorous) processes.

[B] Project schedule is not a prerogative of the team in Agile. It is the marketing team/ leadership which takes the call on this important aspect of the project in Agile Software Development.

There are still others who say Agile Software Development is crazy Cowboy Style Programming because:

  • There is no documentation.
  • There is change – right, left, center.
  • There is no method to define the maintenance phase.

Again, all this is an individuals perception and an emphasis on definitive processes for everything. Nothing in Agile stops you from saying no documentation or little documentation – they only ask you to value the cost of the documentation – which is a good thing to do. If there is a value and cost-value graph is good, then documentation should be made. Agile is based on building frameworks and teams which accept change. This is based on a lot of engineering practices like refactoring, unit testing and automated tests [which leads to cohesion and coherence - both desired qualities of a good code anyways] as well as having a good framework for product managers and coders to interact through out the product lifecycle. Rather than working on the principle that changes caught early in the development lifecycle are easier to fix, Agile focuses on creating processes and environment where changes at any stage can be responded to readily : it makes it easy for development team to suggest alternative ways to get quicker to market as well as get feedback quickly. It also enables them to align their code and design from a business standpoint. This along with engineering practices mentioned above, helps the team respond quickly to changes. Also, it is not a question of change or no change but market environment – can any good product manager give you solid no-change requirements for anything longer than 02 months in current business environment anyways? What is best – to have a slow response to these requirements or rapid responses? If your product is now in the market, probably maintenance will be one area you want maximum attention. Nothing in Agile makes you focus less on maintenance and more on new product development. Agile is a value stream – whatever brings you value, inspect/ adapt for that. It emphasis the system as a whole with clearly defined roles – something which Cowboy Coding does not unless the only way you can derive success is by having everything entrusted to group of developers – which can very well be the case during the initial stage of your project.

Agile Christmas Greeting

Posted in Agile, Collaboration with tags , , , , , , on December 25, 2008 by vikramadhiman

Seasons Greetings !!! May this season and new year bring you:

  • closer to your team,
  • patience to understand,
  • reflection to hold reactions 
AND
  • lots of togetherness, bonding and fun at workplace
Hope you are a harbinger of “we” and “us” and help make your team and organization a better place.

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.

Follow

Get every new post delivered to your Inbox.