In this interview, Scott answers questions about Enterprise Unified Process, Technical Issues in Agile projects and also advises on linkages between “people management” and “technical excellence”.

agilecollab : How did your interest in research into Modeling and interest in Agile/ Lean/ Lightweight methods converge?

Scott : It was my experiences in software development. I saw that the heavier approaches to modeling really weren’t doing much other than employing modelers, yet I still believed in modeling. So I started observing what was working well and what wasn’t, and started writing about it. One thing led to another and the Agile Modeling methodology, www.agilemodeling.com, emerged. It’s important to point out that I’m only the method leader, and that several hundred other people also actively participated in its creation.

agilecollab : Do you think “modeling” and “analysis” disciplines are under threat or reinvention from Agile [or even “a”gile] movement? What are going to be some of the important differences in the way we architect scalable and usable applications?

Scott : It depends on your point of view. The hard-core, traditional modelers definitely seem to be threatened, likely because the approach is so different than what they’ve been taught to do. The traditional approach is to create comprehensive models and documentation, the assumptions being that you need to think everything through first and that the development team will actually follow the detailed strategy. Sounds great in theory but in practice this proves to be very risky. See http://www.agilemodeling.com/essays/proof.htm for some thoughts and more importantly links to supporting research. The agile approach is to focus on collaboration, to model and document just enough as the situation warrants, and to be prepared to change when your stakeholders change their minds (and they always do). This is much more realistic but requires greater skill and discipline on the part of the IT professionals. You should still do some initial requirements and architecture envisioning, see http://www.agilemodeling.com/essays/initialRequirementsModeling.htm and http://www.agilemodeling.com/essays/initialArchitectureModeling.htm respectively, particularly at scale. Celso Gonzales and I wrote an article about Agile Model Driven Development (AMDD) for the June 2008 issue of Better Software magazine, the article should be online in early May, and showed how to use software-based modeling tools such as Rational Software Architect (RSA) to scale agile approaches.

agilecollab : UML was considered the bible for all architects and designers. However, of late the interest in UML has slowed down. Is there a future for UML after the onset of multiple light weight techniques?

Scott : UML is still a critical skill to have, and as you can see at http://www.agilemodeling.com/essays/umlDiagrams.htm the Agile Modeling community takes the UML seriously. Agile developers are still modeling, but they’re doing so far more effectively than their traditional counterparts, so the UML is still important. I suspect that interest has slowed down because UML has truly become a standard and is now part of the IT intellectual landscape.

agilecollab : This is a tough question. You have written many pioneering books as one can see at http://www.ambysoft.com/books/ - which of them you enjoyed the most?

Scott : Writing books is definitely hard work. I think that the one that I enjoyed the most was Agile Database Techniques, www.ambysoft.com/books/agileDatabaseTechniques.html, because it really opened up the world of database development to agile approaches. The data community has fallen behind the rest of IT when it comes to process, they struggle when it comes to quality and productivity, and in short they really need to improve the way that they work. This book clearly provides concrete, proven strategies for doing so.

agilecollab : Tell us about Enterprise Unified Process. The tagline of the book you wrote is “Extending Rational Unified Process”. What prompted the idea for the same?

Scott : The realization that there is far more to IT than just software development, something that is very easy to observe in virtually every IT organization, led me to work on what eventually became the EUP. Up until the EUP the focus of the Unified Process, including Rational Unified Process (RUP), was on software development. While software development is clearly important, it’s only part of the overall IT picture and the goal of the EUP is to address this greater scope. EUP extends RUP to include a Production phase where you operate and support your system and a Retirement phase where you remove the system from production at the very end of its lifecycle. The EUP also addresses cross-system issues such as strategic reuse, enterprise architecture, portfolio management, and others. Since I first started writing about the EUP in 1999 we’ve seen several plug-ins, extensions, to RUP created to address these sorts of issues. The EUP is described at http://www.enterpriseunifiedprocess.com/ and the plug-ins at http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/

agilecollab : How is this different from Agile Unified Process that you talk about?

Scott : The AUP, http://www.ambysoft.com/unifiedprocess/agileUP.html, focuses just on software development

agilecollab : In terms of developer or architect expertise, what are some hard and soft skills, they should acquire to be successful in any light weight method? Also, are the chances of success better with Enterprise Unified Process or XP?

Scott : The most important thing that architects can do is be prepared to be active members of a development team, including writing code. Architects who don’t write code won’t be respected by the development team, increasing the chance that their architectural strategies will be ignored and thus increasing the likelihood that they will fail. Having people skills and a good knowledge of the business is also critical for architects to be successful. In addition, EUP and XP are completely different things due to their scope. A better comparison would be AUP and XP.

agilecollab : Do you see some specific “technical” instances where the “Application Architecture” generally fails in Agile projects? If yes, what do you think are the 03 top such instances? Which of your books would address these reasons the best?

Scott : It isn’t technical issue that causes architecture to fail, it’s “people issues”. The top three issues would be:

• People being inflexible and insisting on creating a detailed, up-front architecture. The architecture should emerge over time on an agile project.
• People not realizing that you need to invest a bit of time up front to do architecture envisioning. You should try to get going in the right architectural direction so that you avoid major architectural refactorings later in the lifecycle. Get the benefit of modeling, which is to think things through, without the disadvantages of detailed documentation.
• People not understanding the need to prove the architecture early in the project with working code. Too many teams get into trouble because they focus on modeling, documenting, and reviewing the architecture – just because you’ve passed the architecture review it doesn’t mean that your architecture will actually work well in practice.
  • The Object Primer 3rd Edition: Agile Model Driven Development with UML 2, is likely the best bet.

agilecollab : Following on from above, what are your top 03 advices to top management when transitioning to Agile and yet want to have some level of surety of their application’s scalability and maintainability?

Scott : My advice would be as follows:

• Promote a working environment based on trust, collaboration, communication, and flexibility. People, and the way that they interact, are the most important factors in software development.
• Recognize the inherent risks of serial, documentation-heavy approaches and actively ensure that your staff understands them. Too many organizations, particularly those that are struggling to retain experienced staff, think that if they invest in significant documentation that they’ll mitigate the risks associated with high turnover. They’d be better advised to invest that money in developing high-quality code and in retaining their staff.
• Adopt a process which has risk-based milestones, such as Rational Unified Process (RUP). Risk-based milestones are a critical strategy for scaling agile software development, see http://www.ibm.com/developerworks/blogs/page/ambler?entry=agile_scaling_strategy_risk_based

agilecollab : Do you see any difference in how “agile modeling” techniques are applied for full languages like Java/ .Net and lighter languages like Ruby or PHP? Which would be the language of your choice?

Scott : Agile modeling is orthogonal to the programming languages that you choose. Of course, different languages will motivate you to choose different models, but Agile Modeling doesn’t specify which models to choose. My language of choice is Smalltalk.

agilecollab : Agile and Usability are generally thought of mutually exclusive. Do you subscribe to that view? If not, what are some convergence areas you see?

Scott : I have to completely disagree with that. About a year ago I wrote the Agile Usability chapter for the book “Maturing Usability”, http://www.ambysoft.com/books/maturingUsability.html. The material from this chapter is summarized at http://www.agilemodeling.com/essays/agileUsability.htm and I clearly show how the two work together.

agilecollab : What is your day like? What are you currently experimenting with at IBM?

Scott : My days are always incredibly busy. I’m helping customers, and IBM itself, adopt agile approaches for large-scale efforts. I’ve been blogging about strategies for scaling agile at http://www.ibm.com/developerworks/blogs/page/ambler. It’s amazing what some organizations are currently doing, and over the next few years we’re going to hear some very impressive agile case studies. I suspect that we’re about 5 years away from “discovering” that agile scales better than traditional approaches. I’ve also been providing ideas and discussing strategies with various product/tool teams, so that’s been very interesting for me.

agilecollab : Do you think Agile is a phase just like CMM and ISO were? Where do you think the movement would be 15 years from now?

Scott : Agile is here to stay, so it will definitely be here 15 years from now. CMM(I) is still quite strong and in fact many organizations are combining the two. I recently ran a survey which explored this very issue, you can download the details at http://www.ambysoft.com/surveys/processFramework2008.html

agilecollab : How are you able to maintain so many portals at the same time? Are there any time management lessons you could share?

Scott : It’s not easy. My wife helps me with some of it, so that’s part of the secret. I also use standard layouts, fonts, … and basically keep things simple as possible. In hindsight it would likely have been easier to only have one portal, but hindsight is always 20/20.

agilecollab : Finally, are there any plans to visit India [IBM or otherwise] as well as what are your plans for the future in general?

Scott : I hope to visit India in August 2008 for the IBM Rational Software Development Conference: India. My plans aren’t finalized yet but it’s looking good. If I do go I’ll also be visiting clients to discuss agile adoption with them. In addition, my IBM colleague, Grady Booch, recently spoke about the Promise, Limits and Beauty of Software with the Rational User Group community in India, so I would encourage your readers to check out the replay at http://www.rational-ug.org/webcast.php#35

agilecollab.com wishes Scott all the best in his future and current endeavors. If you are interested then, the full list of Scott’s books and articles is available at:

http://www.ambysoft.com/books/

http://www.ambysoft.com/onlineWritings.html

• 09:30 AM - 10:00 AM : Registration
• 10:00 AM - 10:15 AM : Introduction
• 10:15 AM - 11:45 AM : Keynote Workshop Session - Part I
• 11:45 AM - 12:00 PM : Tea Break
• 12:00 PM - 01:30 PM : Keynote Workshop Session - Part II
• 01:30 PM - 02:15 PM : Lunch
• 02:15 PM - 03:30 PM : “Common Myths about Agile : A Reality Check”
• 03:30 PM - 03:45 PM : Tea Break
• 03:45 PM - 05:00 PM : “Manager 2.0 : Managerial Role and Competence in Agile Organizations”
• 05:00 PM - 06:30 PM : Fish Bowl Discussion and Closure

Our aim is to conduct the event by the clock [organizers clock :-)] and we will ensure we start “dot” at 10:00 AM and end at 6:30 PM. Our presenters will ensure their sessions are also conducted by the clock and all tea/ lunch breaks would be time boxed [in true Agile fashion] as well. There might be some minor changes in the above schedule but start and end times would be as above.

We are currently working on two venues and will update you on the venue by May 14, 2008.

In case you can not make it for the event, please do let us know by May 14, 2008 - so that we can accommodate people from our waiting list.

You can always get in touch with us for any questions. We also request you to subscribe to agileindia@yahoogroups.com and agilechd@yahoogroups.com and help form the Agile Community in the region and India.

Let’s visit the old SCO model and see how strategic, coordinative and operational activities are carried out by the team and Scrum Master and Product Owner in this regard.

The Team :

• Strategic : The team makes decisions regarding which practices it would use, how much work it can commit to during a sprint, 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, project or product backlog and sprint review with the marketing leadership/ product owner.
• Operational : This is left for the team to identify for themselves. However, 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 checks that the values are being followed or not. 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.“

• Strategic : As per Wikipedia, strategy is a long term plan of action designed to achieve a particular goal, most often “winning”. A strategy is a careful evaluation of current situation, future scenario [multiple] and alternative choices for the same. Selection of one or combination of alternatives affects the outcome and future. Strategic activities and tasks are about defining a strategy [current and future scenario and how best to get there] as well as continually monitoring and adapting. Considerable portion of activities and tasks are focussed on planning for future. The questions strategists ask is : “What do we do?”, “How do we do it?” and “How do we excel?”. These questions can also be expanded to : “What we should be doing?”, “How we should be doing it?” and “How we can become more effective?”
• Coordinative : Coordinative tasks are mostly tactical in nature. A tactic is a conceptual action used by a small unit to implement a specific mission and achieve a specific objective, or to advance toward a specific goal. A tactic is implemented as one or more tasks. As must be clear from the word, coordinative tasks are about coordination. The goal and vision is already defined and to an extent the path is also available [i.e. strategy is in place]. At a coordinative level, different members of a division as well as resources are channelized into specific activity. The focus is on optimal utilization, processes implementation and team work.
• Operational : Operations or processes are a set of well defined, finite tasks to do something. 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. “Hiring right” is an important aspect of any business. As a strategist, the focus is on what are the challenges in hiring right. What are the challenges, where people are being sourced from, what is the quality, where else can they be sourced, looking at hiring practice, training and retaining practice and periodic complete compensation/ competitive analysis. A coordinative task in the meanwhile could be to have core HR professionals focus on activities in training/ retaining practice [conducting trainings, orienting people, laying down processes etc.]. Operational tasks are specific activities like conducting the training as per the process, conducting employee feedback survey periodically, analyzing the results, preparing a report and presenting to suitable people. This is what a typical organization works like as well. The highest value tasks get done by senior most managers or managers. Most managers work in the coordinative or strategic space. This is good. However, Internet world and Agile changes some things.

The default assumption above is that flow of control is top down. An effective strategy in Internet world [and a good strategy should keep this in mind anyways] - flow from bottom to top [and we don’t mean moles], needs to come up as well. This flow should not be just simple feedback surveys. The flow is providing significant autonomy to individual units to align them with goals and objectives of organization/ project “as they want to be”. Hence, rather than focusing much on “how to do something”, a broad framework is 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 which of these would not fit in with Agile world. [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.

Now, when we see the above 03 types of tasks, we see that 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 requires creation of a democratic work space and choice driven coordination up and down the value chain. We will try and explore this further in our next post.

You can still register for waiting list of registrations. In case, there is a seat available, we will definitely get in touch with you.

Mapped Managerial Role Responsibilities :

• The best way to explore managerial role is to understand the dynamics of leadership required for an Agile Project. The three broad areas outlined are marketing leadership, process leadership and technical leadership.
• The marketing leadership is best represented and served by the product owner. The product owner is responsible to draft, defend, articulate and update the products specifications/ features/ requirements. She is the final word on what is to build and when. She should ideally have a deep understanding of what would the customers value. The product failure because it could not stand the test of the market or the customers did not like the product is a product owner’s failure. Product owner in essence controls the pivotal aspect of the product - what is being built, why is it being build and when is it being built. As discussed in the post on product owner, she may take the team’s input but thats only one aspect of the advice. She would listen to customers, conduct marketing surveys, stakeholders, research on product’s features and prepare cash flow plans.
• The process leadership is best represented and served by the Scrum Master or Process Coach. The Scrum Master would be responsible for the success of the Scrum Process. She would ensure things like whether a product backlog exists, whether sprint planning is being conducted, are sprint retrospectives surfacing problems and also conduct a daily stand up for the team. The roots of Scrum Master in servant leadership. The team is Scrum Master’s project and she has to ensure and do everything in her power to make the team successful in working together with Product Owner in developing a quality product.
• Self Organizing Team is responsible for delivering increment of functionality. The team would work with each other, divide tasks, commit to deliverables, ask any questions and pick up practices to do the work. The important aspects are for the team to identify, volunteer, commit to the various practices. The team is the one responsible for delivering the work - its either a 100% done or 100% not done.

Now that we have seen what are the main roles and responsibilities. Now let’s see what does a formal manager do in Agile. It is useful to take XP’s approach. The role of a manager although important but optional. Here are some of the approaches for transitioning a traditional manager  in an Agile environment:

• Become a product owner or scrum master
• Become a Manager 2.0 - we will touch on this in detail in our next post but for now lets just consider these points:
  • Managers continue in their existing role but do not do things that are not as per Agile values and beliefs. The easiest to identify in this case are things like task breakdown, task assignment, task tracking etc.
  • Managers add/ enhance some aspects which will help implementation of Agile. The easiest to identify in this case are things like providing feedback, amplifying learning, educating customers about Agile, functioning as technology or product or process Guru’s, working on next generation products, help Agile scale etc.
  • Managers edit some part of their responsibilities. For instance, customer interaction could mean that they work with customers to define their requirements better, work out business case, define the release schedule, work on competitive advantage of customers, become customer’s value partners. It is important to note that stuff like task management is not included here. Rather, manager can work as a customer proxy and managers then move towards a product owner profile. Similarly, feedback can be restructured on a weekly basis and help people define and attain their goals as well as help facilitate 360-degree feedback [probably keeping their feedback as advice] where the manager provides information as outlined by Esther Derby and other management gurus rather than assess people’s performance.

In our next post, we would discuss what managers typically do and how can they make the transition to become Manager 2.0

Agile is among the most discussed topic in the software development community these days. The traditional ways of developing software are far removed from the way businesses operate. Industry and technology move too fast, requirements change every day, competition does new things all the time, it is age of perpetual beta’s and customer’s customers can’t wait to get hands on the software. In addition, the customers are increasingly demanding unpredictable and new product features. In addition to this, India is now experiencing the third wave of outsourcing - where innovation and value delivery is the key. As a result, several industry practitioners have come up with a set of values, practices and methods broadly classified as Agile. Some of the most popular Agile frameworks are Scrum, XP and Crystal Clear. However, the rise of Agile, has also given rise to many misconceptions and wrong interpretation of Agile values and practices. The purpose of this workshop is to introduce Agile concepts from noted Industry Thought Leaders.

• Senior Management/ Business Managers - Decision makers who want their organizations to adopt practices that value human endeavor and align their organizations as customers value creation partners
• Project Managers and Program Managers - Interested in the discussion of Agile and how their role undergoes a change in Agile
• Team Leads/ Business Analysts - Responsible for customer facing roles in the organization
• Educators - Looking to teach and learn more about Agile Methods

Organized by -

• This workshop is being organized by the Agile Software Community of India (ASCI) and Net Solutions.

Features -

• Talks by Agile practitioners [including a half-day introductory session from Naresh Jain]
• Informal group discussions on topics of interest to a particular group

Program and Venue Schedule -

• There are a total of 25 seats available.
• There is no registration fee.
• The workshop would be a day long event.
• The venue details and detailed program scheduled is Coming Soon!

Contact -

• Contact us at emo@agilecollab.com for further details!!!

Also, stay posted for more details.

• A team is formed and a deadline is worked out.
• The team picks up what it can do in this deadline and off they go building what they committed and at the deadline, they demonstrate working software.
• During the time period between commitment and deadline, the team works together, finding out how they want to track progress, develop, collaborate, divide tasks and everything else that needs to be done to meet the deadline.

The key question is why would this work? It does because the commitment is team’s commitment. In traditional management styles, the management negotiates a deadline, commits the same, decides what all should be done in this time and then tells the team to go do it. This is a bit counter intuitive. The people who are doing the work should know the best on how to do it and how much time it will take to do it. Another reason why this works is because the team has a deadline to deliver quality working software. This means anything that does not contribute towards this end mission [any practice, any team configuration, any team member] is gradually taken out. This also works because the feedback loop is now directly between the team [responsible for building the right product] and the product owner [responsible for constructing the right product feature set].It is important to understand what does “Left Alone” mean here. The team is Left Alone in the sense that no one tells them what methodology to use to transform the requirements into functionality and there is no one but the team to blame if the team fails and also there is no one to bask in the glory other than the team if it succeeds. It is solely and utterly the team’s responsibility to figure out what to do, and to do it. However, there are some basic checks in place - they have to deliver what they commit or let the product owner know if they won’t be able to [and this should happen less and less as the project progresses] and they can ask the management for help in meeting their target [more people, training, removing obstacles etc.] Other than that the team collectively brainstorms and works to meet its commitment. The team self-organizes.

Now that we have discussed, what self organization is, it is important to note some Scrum and XP practices which help foster this self organization.

• Whole Team - The whole team is “whole team”. Everyone required to be involved in converting the features into functionality is a part of the team. If it means copywriters, designers, developers, testers and business analysts all have to be in one team - then that is it. The team also includes the Process Coach or Scrum Master. There may be a a manager as well who would be responsible for logistics, communication and coordinating activities. The idea of the Whole Team comes from eXtreme Programming. XP in fact goes a step forward and also includes the customer as a part of the Whole Team.
• Generalists - A team with Generalists [sharp, efficient, collaborative people] tends to better at self organizing. Why would this be so? This is because the team picks up work, identifies what is needed and sometimes something would be needed and on other times, something else. For instance, on some days, you might need more testers and on some days more analysts and on still others, more programmers. Specialists are unable to change gear while generalists [assuming your hiring practice is good], are able to change gear and collaborate to get things done. This is in keeping with the notion of creating a champion team rather than team of champions.
• Daily Stand Up - The daily stand up is opportunity for the whole team to collaborate and check the progress. They also identify where the most effort needs to be put in and if they are on the target to achieve their goals.
• Big Visible Charts - This is not something we have discussed so far. However, this is a powerful unifying tool. The team sees at all times, what is pending, what has been done and what is still pending to do. This allows them to plan their work better and also volunteer for more work and see who needs help. It is useful to note that if the team knows that either all of them fail or all of them succeed, big visible charts help the team see the tasks that are still to be done and plan for them.
• Flat Hierarchy - It is pretty obvious that if the team is left all to itself but one or two people are deciding what they should do and how they should do it, the team would fall into command and control again. Rather, the team has to be like a crack sports team which can organize itself beautifully depending on the current match situation.

Now that we have discussed about self organizing teams, it is important that we understand when is the team self organizing.  As per Wikipedia, self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Self-organizing systems typically (though not always) display emergent properties. A key characteristic that is generally overlooked is that “something is self-organizing if, left to itself, it tends to become more organized.” A team would not inherently become more organized if left “totally” on its own or without components that we talked about earlier. Without proper leadership or an organization structure that does not support self organizing teams, this would not be possible. Also, the move towards self organizing teams is an ever evolving theme and any equilibrium would be temporary. A single most important fact which management in Agile needs to learn is how to create such self organizing teams/ units. We will touch on this in our next post.

agilecollab : GoodAgile recently conducted Scrum Unconference in Hyderabad. What was the motivation for the same?

Pete Deemer : Over the last year, we have seen rapid growth of Scrum in India and invariably people have asked me during CSM classes and otherwise, on why there are few oppotunities to meet, learn and network. At GoodAgile, we felt like the time had come to start doing Scrum-specific events where people could meet in person, hone their skills, and have a fun time. We also wanted something that we could pull off quickly and without lengthy upfront planning and also have a model that we could replicate in different cities around India.  So we thought the Bar-Camp style UnConference was the right approach. We got a group of people together, and in real-time we created a full day of talks, exercises, and other fun activities.  But best of all, the format was based on the self-organization and self-management that’s so central to Scrum, so it felt “Right”.

agilecollab : How was the experiences?

Pete Deemer : It was great — we had about 60 people from lots of different companies in Hyderabad coming together, sharing experiences, and learning from each other. Scrum can be very challenging especially if you do not have people to network in your own organization, and it’s great to be able to get advice and learn from other people who’ve been through the same challenges and succeeded.  The main thing I carried back was something I’m constantly reminded of, and why I like being in the IT industry — software people, even though thought of as “geeks” by the rest of the world, are some of the most interesting, creative, and thoughtful people you could ever meet!

agilecollab : Tell us about your implementation of Scrum in Yahoo? What metrics did you guys track to know that Scrum was successful?

Pete Deemer : We did gather metrics, but for most teams, we didn’t need the metrics to tell us Scrum was making a significant difference — the results in business value and team morale were pretty apparent to all.

agilecollab : Based on the above, what is your advice to companies transitioning to Agile?

Pete Deemer : If it’s worth doing, it’s worth doing properly — get the best training and coaching you can find, and make sure the entire organization understands and can support the team’s efforts. 

agilecollab : At what stage do you think is Scrum awareness and implementation in India?

Pete Deemer : Over the last year or so, there’s no question it’s entered the stage of rapid growth. Almost all the best-known IT firms in India have teams using Scrum now. There are lots of people in many companies in India, who are holding on to the values of Scrum, working to implement Scrum properly and trying to improve the way their businesses are run. There are many conferences and events being held as well. We would like to support such people. The challenge now is helping people be as successful as possible within the specific context of India, and helping grow the expertise. Having unconferences and speaking at other Agile and IT events is an effort in this regard. We have also started the Scrum-India Yahoo Group, which is again another opportunity for people to share and learn from fellow Scrum users.  I also appreciate the effort that www.agilecollab.com is making - this is coming up great and explains concepts to beginners in a simple fashion.

agilecollab : Do you think it makes sense for outsourcing/ service companies to use Scrum?

Pete Deemer : Absolutely.  If speed, quality, and “getting it right for the customer” are your part of the value you offer customers, you should definitely consider Scrum. This is not always going to be easy. However, the results can be dramatic, and a lot of teams say “I wish we’d discovered this sooner!”

agilecollab : What are the benefits for customers in choosing a company which does Scrum or true Agile rather than one which does not?

Pete Deemer : Some of the biggest benefits of Scrum for the customer are visibility into what’s being produced, and “is it right” — and the ability to rapidly iterate, without lapsing into chaos or thrashing. It in a way also helps you focus and participate. Scrum does require a more involved approach from the customer side, but only for their own benefit. One risk for the customers is that there are a lot of companies who claim to be doing “Agile”, but are in fact just using it as a marketing label — so I’d recommend choosing carefully.

agilecollab : You conduct lots of trainings and CSM classes in Bangalore and Hyderabad but comparatively lesser in NCR or North. Why do you think north India lags behind in Scrum awareness?

Pete Deemer : I’m not sure why this is — especially since there are leading Agile companies and also others who are exploring Agile, in the Delhi area and from what I hear, in Chandigarh too. I think we’ll see more and more growth in the north in the coming year.

agilecollab : Finally, what are goodagile plans for new year?

Pete Deemer : The plans for the coming year are many. I am traveling all across India and Asia, helping people learn about Scrum. We hope to continue to spread the Agile and Scrum message, and help companies succeed with it!

agilecollab.com, wishes Pete all the best for this year and always.

Scrum was getting popular almost at the same time as Mary Poppendieck was theoreticizing the various aspects of Lean. In a way both Scrum and Lean have their origin in complex adaptive systems theory. The origins of Scrum are best explained by Jeff Sutherland in his blog post. The conclusion in this post point to the fact that although Scrum can be in some ways viewed as a partial Lean Process, it is not a descendent of Lean. Also, if the concepts of Lean are applied within the Scrum framework, the results would be akin to what companies like Toyota have been able to achieve in product development. A more detailed look at Lean would be coming a bit later, but for now, lets look at the 7 principles of Lean and how these are achieved/ mapped to Scrum:

• Eliminate Waste : The work in progress is just that : work in progress. It is absolutely useless till it reaches the customer. Anything that does not add value is a waste. The biggest waste in software are unused features and features which do not provide value. In fact, the features which do not provide value are not only a waste but also a drain. Typically, this happens when the longer a product takes to reach the customer. This means that there are chances of product being either developed with a process that generates waste or you are building something wrong. A process where bugs are found after coding, would require you to go back to redo the coding. This would again be a waste. Scrum mandates work to be performed in a series of sprints, each sprint being of a very short duration. At the end of a sprint, the team should demonstrate potentially shippable code to the customer. Hence, the basic framework of Scrum would ideally guide you from incurring waste. However, an important component to minimize waste is to see and recognize it. Scrum does this by asking the team to identify obstacles. If the team is not capable or empowered enough to raise these obstacles, Scrum would probably not work as won’t Lean.
• Build Quality In : The focus of a Lean Process and Enterprise is not to have defects occur in the first place, rather than enter them in defect tracking queues. If you really want quality, you don’t inspect after the fact, you control conditions so as not to allow defects in the first place. If this is not possible, then you inspect the product after each small step, so that defects are caught immediately after they occur. In Scrum, the focus is more on latter. The fact that you demonstrate potentially shippable code at the end of each sprint, the team is subjected to rigorous test of what they are developing. As we have seen the sprint review also works as test for product owner in addition to the team. In addition, the team can raise obstacles which affect their productivity. When Scrum is coupled with XP, the team tries new development concepts like pair programming, refactoring and test driven development. These concepts help build quality in the processes. Hence, Scrum and Lean seem to be aligned here as long as the team picks up the right development practices. However, Lean takes an even more radical approach which you do not find in other frameworks. Lean says that When a defect is found, you stop-the-line, find its cause, and fix it immediately. The concept is drastic and at least initially can lead to the team stopping work all the time. The Scrum approach of identifying obstacles at the daily stand up and then Scrum Master either resolving them right away or wait to discuss these during sprint retrospectives, is a good alternative as well, at least initially. In Scrum, you regularly inspect and adapt and there are other drastic measures like sprint cancellation available with product owner.
• Create Knowledge : One way of gathering knowledge about your product is to get experts, pay them enormous salaries and create a 1000 page requirement specification. The other is to understand what customers really want by focussing on minimum, releasing that to actual users, getting feedback and developing from there. The latter approach has been there in various aspects like JAD, RAD, Prototying etc. However, the approach Lean [and in an implicit fashion, Scrum] take is that real knowledge about product starts coming in only when product hits the market. The sooner this is in its life cycle, the better, the knowledge would be. Another aspect of knowledge that Scrum and Lean share is that best knowledge is tacit knowledge. Through a self organizing team which learns, works and shares information, together, both aim to have a “information workspace”. The knowledge about the process, obstacles and product are gathered by the “whole team” at the end of sprint through sprint reviews and retrospectives.
• Defer Committment : Scrum is silent on “implementation” aspects of this value of Lean. However, the product owner is expected to write a good product backlog keeping in mind various aspects like priorities, risk, YAGNI and set based concurrent engineering approach.
• Deliver Fast : According to Lean, there is only one way to achieve high quality. You must develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors. Scrum is a framework which provides for faster delivery of products - almost every sprint. However, there is nothing in Scrum that stops the teams from delivering poor quality, same mistakes driven and late software. Scrum would only make it visible. It is for the organization to create a culture where the team members can continually work to improve processes so that they can continually work at an even faster pace.
• Respect People : There is no one best way to do something. There are many ways. What is a good way to do for you might not be a good way to do for others. If you give respect to people, you get that in return. You must respect people and this should be demonstrated by your single minded dediction in helping them succeed. When this is done, the people align themselves with your vision and produce astounding results. Scrum and Lean encourage self organizing teams. The framework respects teams judgement, responsibility and ability to organize and plan work. Hence, this value of Lean closely aligns with Scrum philosophy.
• Optimize the Whole : A lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, the overall value stream will suffer. Scrum is a simple framework. It optimizes the three parts of leadership : processes, marketing and technical. Of course, the system would be as good as the people in it.

As we can see, whether or not Scrum tends towards Lean is driven by what the team and stakeholders value while implementing Scrum. In fact, there’s really nothing to stop you from using Scrum to schedule a more rigorous workflow like the SEI Process.

Scrum would approach project management by requiring the Product Owner to specifically outline the vision and tentative release dates for a product/ project. She is also required to draft an initial set of requirements and sort them by priority in what is called a project or product backlog. The team then gets together with the Product Owner and estimates the requirements broadly. The Product Owner can then re prioritize the requirements, if needed. Once this is done, the Agile iterative and incremental process starts. The team takes a guess at how much work it can do in a particular sprint. They pick the requirements that can fit into the first sprint, re-estimate them better and to a finer detail. This might involve asking Product Owner more questions. This is done usually during the first half of the Sprint Planning Meeting. Once the team and the Product Owner come to an agreement on what requirements are to be taken up during the first sprint, the team moves to second phase of Sprint Planning Meeting and breaks the requirements into actual tasks constituting what is the initial sprint backlog. The sprint clock has now started.  These tasks are updated through out the sprint in what is called a sprint backlog. The team meets daily, to synchronize the efforts. At the end of the sprint, the team demonstrates potentially shippable code to the Product Owner and other stakeholders in Sprint Review. The team incorporates feedback and Product Owner reprioritizes the backlog. Both decide the date for next Sprint Planning Meeting and start another sprint afterwards. Between the next Sprint Planning Meeting and Sprint Review, the team undertakes a Sprint Retrospective. The team identifies process improvements during this meeting and over a period of time, sprint after sprint, takes an iterative and incremental approach to process improvement as well. A Scrum Master, is designated with the task of ensuring that Scrum is followed in spirit and letter.

This was more of a How-to of Scrum. We would discuss a Lean view of Scrum in our next post.

Interactive Media Awards Best of Class Award in Web Design/ Development

Horizon Interactive Award - Bronze Category 

Web Marketing Association Award

W3 Silver Award in Visual Appeal and Lifestyle

Raja Choudhury, our client helped bring not only a Product Owner but a Product Architect vision for the project. Read more how we brought our strong account management, project management and technological skills as a part of global delivery team to develop this beautiful portal.

agilecollab : Please tell us how were you exposed to Agile?

Naresh Jain : Back in the dark days of my life, I was working as a coder (not programmer) on a big J2EE project. This was for a IT division of a big Bank. We had a really smart Architect sitting in UK who would provide development guidelines. One of his guidelines was, as soon as we finish a feature, we were supposed to write JUnit tests before we check in the code. As soon as any team member would check-in code, he would check out the code on his machine and do a code review (he literally acted as our Continuous integration build server). For those of us who had never written a unit test, this was a boon in disguise to avoid stupid mistakes. As I got used to this approach of writing unit tests after the code was written, I felt I was wasting too much time building the wrong code. My test would give me the feedback that I made a silly assumption. This feedback was great, but I had already spent the time writing the wrong code. My manager always told us, work smarter not harder. So in the search of smarter ways to do the same, I stumbled upon the life changing article “Test Infected“. The whole Test-First approached seemed so much superior than what we were doing. And thus began my journey into the Agile world!

agilecollab : What has been the motivation behind ASCI?

Naresh Jain : Scratch your personal itch! While I saw a clear value in Agile and light-weight methods, there were very few companies in India who actually knew about these methods. Agile was making big news in the west and community based conferences was a growing trend there. In late 2004, Owen Rogers and Manoj Bharadwaj were planning to organize a one day conference in Bangalore similar to the XP Day. Manoj spotted my interest in community building and asked me to help them. I was very interested and happily joined forces with Owen and Manoj. Soon the conference planning started picking up steam. At one point, (a month before the conference) we had to figure out a way to manage funds. So we wanted to open a bank account. We realized that it would be difficult to open a bank account without having some kind of an organization. Since this was a non-profit event, KK Rajan suggested we register a non-profit society and open a bank account in its name. Bhavin Javia suggested the name ASCI - Agile Software Community of India. And today we have ASCI. So what started off as a means to handle funds for a non-profit conference, today is grown into a large body of Agile enthusiasts and practitioners. Today ASCI provides a platform for people from different software organizations to come together and share their experience with Software development methodologies. ASCI’s focus is Agile and related light weight methodologies/philosophies. ASCI evangelizes itself to be a facilitating body which fosters and innovates lightweight methodologies in software development in India.

agilecollab : How can one become a member of ASCI?

Naresh Jain : We believe in keeping it simple and lean. Details : http://agileindia.org/membership.htm

agilecollab : What are the plans for coming year and ahead for ASCI?

Naresh Jain : While Agile is got into mainstream, there are a huge number of organizations in India who want to adopt Agile. So the focus of ASCI has shifted from Agile awareness to Agile adoption. ASCI’s model to achieve this has mainly been through conference and user groups. We have consciously not got into training and certification. And hope we’ll never get into it. ASCI has just formed a new board and I think this board will take ASCI to the next level.

agilecollab : How have last few years been in adoption of Agile principles and practices in India?

Naresh Jain : There has been an exponential growth. In 2004, there were hardly any companies that were aware of Agile. Today most of the big companies have piloted at least a few projects using Agile and some companies are using Agile principles and practices in majority of their projects. Smaller companies have found it easy to adopt agile while the big CMM companies are getting there.

agilecollab : Do you think the motivation for adopting Agile is more in product companies than IT Services companies?

Naresh Jain : I don’t really have data to say whether its more in product companies or in services companies. There are a large number of companies in both categories that are adopting Agile. In the product space, time to market and improving efficiency/ productivity is driving the adoption. In other words, the motivation is mostly internal. While in the services space, competitive advantage and customer/counterpart pressure is really driving the adoption. In other words, the motivation is mostly external.

agilecollab : Is there a regional bias in India with regards to Agile adoption, with South leading way over North?

Naresh Jain : Based on my interaction with various companies all over India, Bangalore has the highest number of companies practicing Agile. Also in terms of their experience, Bangalore seems to have lot more companies with pretty good understanding of Agile. Having said that, companies in Pune, Mumbai, Hyderabad, Chennai, NCR, Chandigarh, etc are catching up big time. But, I think Bangalore does have the first starter advantage.

agilecollab : According to you, which of Agile frameworks fits better in Indian context?

Naresh Jain : In my personal experience eXtreme Programing, Crystal and Lean are the frameworks from which companies in India will really benefit. Scrum would also be important form a marketing perspective. For Ex: A services company can bid for a project saying “We have 5 certified scrum masters”!

agilecollab : What according to you are major factors which impede organizations journey towards agility?

Naresh Jain : Organization Culture and People’s attitude towards change.

agilecollab : We have started Agile Chandigarh [users can join on LinkedIn and Yahoo Groups]. It is at a nascent stage. However, it would be probably only second such group in North. What advice would you give to the group?

Naresh Jain : I’m nobody to give advice. But now that you have asked. I have 3 advices:
1. Perseverance
2. Perseverance
3. Perseverance
It takes a bloody long time for people to invest time in user groups and to value free peer-to-peer community based learning. Most people want an easy way out. Pay, sit through a class for 2 days and walk out with a certificate. Now that we have taken the first step in the right direction, I think 50% of our job is done. Also remember ASCI will live as long as such initiatives are taken by people in different parts of the country.

agilecollab : Finally, any plans to visit Chandigarh?

Naresh Jain : Not that I know of. But if you plan to organize a Agile Chandigarh 08 Conference, you can count on me to move the boxes.