In our previous posts, we have emphasized the importance of a self organizing team. Self organization is a simple concept.

• 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.

Popularity: 9%

Posted on April 21st, 2008 by admin
Filed under: Collaboration, Maturity, Practices | No Comments »

Sean Devlin, contacted Net Solutions in 1997 to build a flash website. After that, he joined Monster.com and worked on some cutting edge features for them. After almost a decade Net Solutions heard from Sean again. Sean had partnered Brad Downs to work on a revolutionary online product, which has subsequently rewritten how universities across United States manage their sport athletes, recruits, alumni and events. The product is Frontrush. The success story continues with many records broken and accolades earned. Net Solutions, a part of this phenomenon right from the inception, is proud to be the development outsourcing partner for the premier University Sports Management System.

The project started as fixed price project in early 2006. During the pre-sales stage itself, we did some rapid screen mock ups and quickly went to development. Manoj Kalra, who had joined Net Solutions a few months back was the lead developer for the project. The project was developed much ahead of schedule and we were discussing Phase II of the project in May 2006 itself. While the first phase of the project was mostly about creating basic functionality for coaches and assistant coaches to manage recruits, rosters, notes and duties - the phase II added the calendar for events/ duties/ notes as well as stronger administrative control. Like Phase I, Phase II was also completed ahead of schedule and in late 2006, we were already to Phase III. Phase III focused on personalization of each coaches area with custom form fields, stronger search features and interactive AJAX features. As Phase III was being developed, the product was under extensive testing and demo at target universities and through some coaches. It was also the time when the first sales were made. Up till Phase III, we had worked on a fixed price approach. We quoted for each Phase, delivered a project plan and delivered much earlier. This was in large part due to an effective product owner role played by Sean. Sean made himself available at India times, almost every time we needed him to be available. He gave feedback quickly, helped us work in short weekly cycles, maintained a very clear prioritized requirements roster based on approved features for each phase and keep our focus on particular week’s deliverables. All the three releases [I, II and III] were delivered without any priority 1 or 2 bugs and much ahead of schedule. The application was beginning to take shape.

It was roughly around a year since Net Solutions and Frontrush had been working together. Also, the product was now in the market. The changes, customizations and support requests for each university were different than others. In addition, strategic liaisons with third party products like email template makers were being explored. At this stage, Net Solutions introduced the idea of abandoning Phase wise approach and working with a requirement roster for only few weeks. Sean agreed to try out the idea. Sean agreed to the idea and discussed the same with Brad as well, who seemed excited about the idea. Net Solutions history of good deliveries and retaining the same team only helped make the decision easier. While coming to Phase III, we had already demolished the hierarchical structure of project management from the project altogether and Manoj was the primary contact for the project for Sean. Going forward, Manoj was primary contact for Sean with a Business Analyst helping Sean define requirements/ acceptance test criteria as needed. The first test of this engagement was a delivery 6 sprints later. A lot of functionality - search, performance, usability and also a critical email template integration for emails being sent from Frontrush by various coaches was being deployed. And we were able to do this on time. After this, the team really took off. Sean and Manoj were on MSN almost daily discussing priorities, checking features and making each sprint a success. The whole of 2007 saw Sean and Brad travel across United States and add one prestigious client after another. The development team in India supported them through quick turn around of demo requests, feature integrations with existing university websites as well as customizing any parts of Frontrush as needed. In late 2007, the team grew even more as we worked on releasing yet another Frontrush product - Camper : a solution on the lines of Frontrush, but targeted at recruit screening camps. The team once again pulled off the product and integration in less than 03 months. In the meanwhile as Frontrush continued to grow, we also worked on support, performance tuning and upgrades.

Frontrush has been a delightful journey for all involved. Net Solutions holds Frontrush as one of its premier projects and is working with FR team in US to now increase the market lead even further.

Popularity: 16%

Posted on March 11th, 2008 by admin
Filed under: Case Studies, Collaboration | No Comments »