jump to navigation

How to Be a Good IT Customer August 7, 2008

Posted by newyorkscot in Agile, Articles, Client Engagement Mgt, Management.
add a comment

Joe Morrison and I have another article published in eBizQ that discusses on how clients and customers can help developers do a better job in delivering better functionality in a quicker timeframe. See also our previous article published in Computer Weekly.


Waters Magazine: Flying By Wire August 1, 2008

Posted by newyorkscot in Agile, Articles, HPC, Marketing, Markets, Other.
Tags: ,
comments closed

Waters Magazine has just published my article “Flying By Wire” in its Open Platform section of the August issue. The article discusses how advanced trading systems need better control systems to dependably innovate and take new opportunities to market. I draw an analogy between trading systems and modern jet aircraft where stability, performance and control are essential characteristics that need to be considered during design, development and testing. Read the article on the Lab49 website here.

How To Be A Good Customer July 8, 2008

Posted by newyorkscot in Agile, Articles, Client Engagement Mgt, Marketing.

Joe Morrison and I just had an article published in Computer Weekly that summarizes how business customers can play a role in IT teams delivering better software more frequently and reliably. Read the article at Lab49 here, or online here.

Mingle April 15, 2008

Posted by newyorkscot in Agile, Client Engagement Mgt.
Tags: , ,
add a comment

One of our guys just downloaded the latest version of Mingle, the project collaboration software from Thoughtworks. On initial inspection it seems to provide a nice visual interface to specify and layout features, tasks, etc for different views of the product and iteration backlogs (including a Card Tree for laying out cards in what looks like an org chart). It also supports some pretty slick (and configurable) burndown charting for whatever data you are interested in, and has a wiki for documentation. It seems to be striking a decent balance between developer collaboration and management reporting.

One feature in particular that looks really useful is an interactive online version of a card wall.  Not only is this customizable, but it can total up work effort per swimlane (which is what used to pain me when we used to use real cards & pinboards). Pretty cool stuff.

Will be interesting to see what others think of this compared to XPlanner, etc, and whether people will pay for it (it costs for projects with more than 5 people). What do people think of this compared to other “paid-for” offerings from vendors such as VersionOne and Rally ? On initial glance, it looks very functional and seems to be very flexible.

Quick Burndown Chart Update March 7, 2008

Posted by newyorkscot in Agile, Client Engagement Mgt, Management.
add a comment

In a previous posting, I mentioned that we had been using Google spreadsheets to track iteration backlogs and to create burndown charts for our agile projects. At the same time, we had been using our wiki for capturing all project-related risks, issues, dependencies, decisions, designs and documentation. Well, the good folks at Google now allow chart publishing (to a URL) such that we can now keep our burndowns “live” in the project wiki for clients to see. All I need to do now is find the right confluence plug-in to allow me to keep a live product backlog in the wiki (Google also allows spreadsheets and cell/named regions  to be published to URLs in various formats).

Delivery Of An ABS Pricing Platform For Interactive Data April 19, 2007

Posted by newyorkscot in Agile, Client Engagement Mgt.
add a comment

We have been working since last summer on a brand new shiny pricing platform for European Asset-Backed Securities for Interactive Data Corporation (formerly Financial Times Interactive Data). IDC just made the a press release about it –read it here and on the Lab49 website.

The cool thing about this project is that is was built from scratch, was run as a formal Scrum project, was developed offsite in the Lab, is part of the client’s new strategic architecture, the client-side stakeholders were a joy to work with, and our team rocked !!

I will write more details on the project later, and will hopefully get a brief case study up on the Lab49 website soon.

Agile Team Scaling August 15, 2006

Posted by newyorkscot in Agile.
1 comment so far

Decent article here from Dr. Dobb’s Portal on how to scale agile projects.

In our experience, on a discrete project basis, a small team of senior engineers will generally always outperform larger “less senior” teams (depending on the success criteria of course!) especially when working with trading, pricing and risk management systems and their ever-changing needs. The real problem in scaling becomes evident when different groups need to integrate their part of an overall solution. In too many cases in Financial Services, each component of a Service Orientated Architecture for example, is so generic (ie not a fully encapsulated service) that is not actually that useful on its own. And end-to-end programs/workstreams that try to stitch these components together are incredibly guilty of taking the ‘command and control’ approach to planning, design and implementation. This forces any agile work down into the grass roots, and limits its adoption across an organization. It can also seriously hinders client-developer communication and feedback. Release planning and integration also become a nightmare and highly frustrating for the agile team (I assume non-agile teams are also frustrated but that is modus operandi).

I am glad to see Collaboration getting a good profile in the article, as it is absolutely paramount to successful agile development, let alone scaling it. We have had a lot of success both internally and with clients in using a wiki to provide complete transparency, continuous updates and real-time issue/risk management — but it is only one part of the solution. Executing larger scale projects needs a high degree of interaction and collaboration on a number of levels including client-driven planning, continuous communication & feedback, daily stand-ups (team and Meta flavours), and in-your-face planning & retrospectives. For distributed teams, even if the teams have actually successfuly worked together before, the initial planning (iteration zero?) phase MUST be physically done in person (a la Agile Modeling Driven Development, if need be) — to establish a real working relationship and sense of trust and understanding, especially for those darn conference calls you need to work your way through ….

More Agile Chart Options August 14, 2006

Posted by newyorkscot in Agile.
add a comment

As I mentioned before, our task-driven estimation on our project iterations drive burndown charts that we continuously update and expose through our wiki.

I found this article on Big Visible Charts which has some great ideas for test and story-driven development… very intuitive. One of the charts includes a data series that shows changes in stories, and the resulting change in expected ship date of the product.  Related to this (kind of), we have really caught the attention of our client stakeholders on one project by adding a “descoped” effort onto our Burndown as this really tells a story of what going on with the delivery team (in this case, getting bogged down with wrapping legacy code and integrating with external systems). Clients generally do not like things being descoped as they are normally the ones that try to add to scope and effort !! Still, the “big visible chart” started a conversation …. which is the point.

95 Theses .. and social networking July 28, 2006

Posted by newyorkscot in Agile, Management, Marketing.
add a comment

I was reading ConfusedOfCulcutta the other day who had blogged about Cluetrain and this geek version of the 95 Theses. The Cluetrain Manifesto has some interesting ideas, witty observations and a very healthy amount of rant against the establishment (one of the authors created RageBoy). But it is not for everyone, example here.

Whatever your take, there were some interesting anecdotes and points in Cluetrain that have some relevance from a social networking and collaboration perspective in financial services, and specifically technology in FS. The truth is that our industry is really not that big in terms of the network of people within it, and therefore the relationships we have and cultivate are critical to building a successful business. Close relationships are built on trust and a record of delivery. Once you have them, you have to protect and nurture them. If you lose them, game over. 

One of the main themes in Cluetrain is that of the markets being conversations. I do agree with this, however I think that conversations and the human/social aspects are the fuel that drives the markets and instills a sense of belonging and community — but from a business perspective you also need to have a product or service that has value, is differentiated and can be delivered well.

Another thing they talk about is the use of the human voice over mass-marketing and corporate messaging. This, I totally agree with. None of the people we work for, nor those we would like to work for, want to hear the sales-pitch and marketing fluff. They want to hear what you do, how you do it, as well as your view and opinion. They want to understand and relate to you as a person, and as a proxy for the other people in your organization. They are humans too and will make judgements, have emotions, opinions and sensitivities. Ramming some corporate marketing-speak down their throats is not what they are looking for –  especially when the conversation is technical. A more honest, open and candid approach has always worked better for me when talking to clients, partners, journalists, analysts and other market players. Respect and trust are earned, not bought. In the (partial) defense of marketing though (which gets a good old kicking by Cluetrain), I do believe that it can add value in places such as helping to formulate valuable strategic partnerships (yes, via conversations!) across the market to create interesting service oferings, or providing a support function to both the sales and engineering organizations. Marketing can also help to foster internal communications as well as exposing the company’s real people to the outside world (via blogs, for example).

There is a lot of discussion about an employee-led organization versus the command and control modus operandi. This is where I think some balance is needed. First and foremost, I believe that maximizing transparency to everyone in the organization is important to fostering an open and respectful environment in the workplace. This has to be opened up across all functions (engineering, projects, marketing, sales, recruiting, etc) so people can really get to see what everyone is doing, how they are doing it, and question why they are doing it at all!  Today’s social software is a key aspect that extends much of what is said in Cluetrain (specific elements of which, such as wikis and blogs etc, were missed in Cluetrain as it was written in the late ’90s). This social networking will help to foster open communication, feedback and innovation within the company and even (but not always!) with clients. It is nice to see some companies such as Dresdner adopting social networking as a corporate policy (they use Socialtext for their wiki).

[Sidenote: Open source communities are a great example of where borderless collaboration rely on natural human dynamics to innovate and develop technologies that we can all benefit from. It is nice to see (finally) that some financial services institutions are relatively wholesale in acknlowledging that these tools & frameworks (Spring and Hibernate being obvious examples) can and should be leveraged, but maybe that is because a) the maturity of the technology has progressed and its adoption has “crossed the chasm”  and/or b) the cost-structure outweighs their natural risk adversity !!!]

Getting back to employee-driven organizations, where people want to get involved in many aspects of the company they should be encouraged (within reason). Where people do not want to broaden their role or responsibilities, that’s cool with me as well. That said, I think there are some things that do require a certain amount of “control” albeit with the appropriate amount of feedback and insight from the ranks. Things like finance, legal, HR and certain aspects of sales do require a certain amount of sensitivity and confidentiality. For me, the most important thing is to leverage people for what they are good at and to support what they would like to do. Imposing articifial barriers, filters and restraints is counterproductive to both innovation, as well as delivery of the company’s services. We want leadership over management !!

From a project delivery perspective, I have always subscribed to some of the same human/social aspects of agile development. Self-organizing teams that have been given the reigns to get the delivery done, but supported by a “facilitaor / impediment remover”, aka the Scrum Master in Scrum, demonstrate how well the theory can play out in practice — when executed properly. Over several iterations, the language the team speaks, the dynamics, the comradery and their productivity simply improve in orders of magnitude. Some of this is due to improving their understanding of the business or technical domain and the use of certain solid engineering practices (continuous build & integration, refactoring, code reviews, etc). But I think most of it is down to the social and interpersonal dynamics that come from the close collaboration with end-users, regular feedback, daily stand-ups, and team retrospectives. As I also previously mentioned, wikis are brilliant in supporting iterative development.

At the end of the day, if you provide a collaborative, challenging and fun workplace for your people, they will help you communicate with and deliver for your clients and their people. I am not suggesting that it easily results in the ultimate, most heavenly blissful corporate paradise that some would have us subscribe to, but it would certainly make our life (at work) that much more rewarding and certainly a lot more fun….

Burndown Charts, Wikis & Spreadsheets July 21, 2006

Posted by newyorkscot in Agile, Client Engagement Mgt.

We have been executing a new client project using a set of iterative development tools & techniques, with Scrum as the overarching management process delivering on 30-day deliverable cycles. Accordingly, the burndown chart has been updated daily based on the work effort remaining for each task the team has defined in its iteration backlog.

In general, when we show and examine burndown charts with clients for the first time, there is definitely a “wow” factor, as this simple visual display contains almost all of the information they need to readily understand the project status. When we then present this information to clients via a Lab49 client wiki page (we use Confluence ), which contains a continuously updated set of issues & impediments, it tells a very detailed account of the project and gives the clients more transparency than they have seen before.

For this particular iteration, we thought we would try using Google spreadsheets to manage the tasks & work remaining — this has been decent tool to allow a single-point for the entire team to update progress and Google’s (AJAX?) front end offers a decent chatroom function for those viewing the spreadsheet. Like a few other collaborative spreadsheet services I have tried (such as Num Sum) the lack of charting is a pain as I have to export the data to Excel but all in all the benefits of the collaborative data management outweighs this. I have tried other agile tools such as XPlanner, but often pefer the simplicity and flexibility of a spreadsheet.

Going back to the burndown …. most traditional project management techniques do not provide an intuitive and simple way for the team (and client) to review how the project is progressing on a daily basis, nor do they provide such a granular level of refactoring of estimates of work remaining. 

One of the interesting things in looking at the burndown is the easy nature by which the team can see how far ahead/behind schedule (relative to a “perfect burndown”) the iteration is at any point in time. (This key feature is not readily available in traditional techniques). However, the daily inspection of both task-level work effort and iteration progress provides a higher frequency of datapoints, which in turn drives a really granular view of trend shifts where small deltas in the overall trend might actually highlight underlying issues and risks that may have otherwise have gone unnoticed. In other words, the trend is can be more insightful as the data itself.

What I would really like to have is a truly collaborative online spreadsheeting function that contains more powerful formatting, analytical and graphing functionality, that I can then reference in-line from my client wiki page to provide truly dynamic updates. I see (one example here) that Dan Bricklin ( the co-inventor of the original spreadsheet – VisiCalc) has developed WikiCalc has some ideas in motion, including working closely with Socialtext. Other suggestions welcome …

Terminating An Iteration June 21, 2006

Posted by newyorkscot in Agile.
add a comment

A few of us were discussing what would constitute a change in requirements that would cause a development iteration (or Sprint in Scrum terminology) to be abnormally terminated, ie what would be so serious (and/or costly) that you simply could not carry on with development ? Here's a recent example (kind of) from the aerospace industry..

Airbus's new A380 is facing production difficulties which does not bode well given the relative success (or progress) of its competitor, the Boeing 787 "Dreamliner" : the 787 is made of lighter composite materials that allow higher cabin pressure and humidity, adding to passengers’ comfort, as well as providing a wider layout for more seating. Airbus has therefore tried to counter the 787's relative success by "refactoring" its existing A330 aircraft to create a new A350 (in addition to continuing the A380)

However, during development of the new A350, Airbus found out that the airlines actually want a "wider fuselage" – that would have been a nice requirement to know about at time of upgrade specification !!  This was always going to be a very expensive refactoring effort from A330 to A350 ($5bn), but not as costly as ignoring the change in requirements. Hey –what's an addition $5bn when all you have to lose is most of your market share to Boeing ?

(OK, so their development cycles are a touch more than 30 days, and they are probably pretty spec/documentation heavy, amongst other non-agile activities, but at least they listened to their customers ! )

Agile Team Dynamics January 27, 2006

Posted by newyorkscot in Agile, Client Engagement Mgt.
1 comment so far

Most of the challenges some of our projects teams face are generally not technical — they tend to be business (or political) issues; a new team getting to know one another and evolving their style as a team; or, the team getting to grips with the business domain they are operating in. This is mainly the case when the team is made up of our staff, client mgt, client developers, and other consultants. In these situations, the team dynamics seem to be the most common thing we have to help teams out with. Politics are another (but never-ending) story.

I have been sitting in on some of the daily stand-up meetings, sprint demos, retrospectives and planning meetings on a few of our agile projects. It has been interesting to see the dynamics of these “cross-entity” teams at play as they follow the Scrum process. As is the case in most situations, you can’t just flip a switch at the beginning of the project and expect the entire team to be executing the process perfectly. There is always some coaching/mentoring/educating required to make sure EVERYONE is doing what they need to do. On one of the projects, during the Scrum and the planning meetings you could observe that boundaries of responsibilities were being crossed (e.g. Product Owner vs Scrum Master vs core team). So, one of the things we did (other than re-emphazing the process) was to have the team create and agree to some rules to help improve the team dynamics and to emphasize that they need to stick up for one another. The following rules were posted in the team room:

  • Emails should be BANNED for inter-team communication. If you have a question, issues, problem with someone on the team or the way things are being done, SPEAK to the person or the team.
  • Decisions made by the team UNANIMOUSLY should be communicated to the entire team – wikis, etc – emails ARE good for this. Examples, include decisions regarding designs, clarifications of ambiguities, development process, etc.
  • The entire team must UPDATE ALL TASKS in the Sprint Backlog before they go home at night. No exceptions.
  • The whole team is accountable for all tasks and estimates.
  • If you don’t agree with something that a team member says or does, or if someone puts you on the defensive, SPEAK UP and stick up for yourself and let them know how you feel (really feel – “Honesty Is The Best Policy”). If the team is not making unanimous decisions it is not working together as a whole.
  • If the team believes it has hit a barrier or estimates suddenly jump, such that THE TEAM thinks it will not deliver on time, then it is time to raise it to the Product Owner (for potential de-scoping). If the team still honestly believes that it can make the deadline, then thats OK – it just needs to agree collectively to get through the workload accordingly.
  • If(or when!) there are issues, problems, etc it is very important that the whole team understand the issues clearly and the entire team understand the solution. This way a) you all know what happened without ambiguity and b) the team knows how to deal with it going forward, and c) reduces dependencies on individuals.
  • There is no such thing as ‘lost time’ – either a task was not completed due to impediments or estimates are recalculated due to needing more time, or you put a task on hold and pick up a new one.
  • There is only one PRIMARY metric – deliver or not deliver ….

The result was that in the 3 subsequent sprints the team delivered when they said they would (and yes, there were 1 or 2 things dropped from scope), and you could actually see some pride and smiles in their achievements.

The reality of introducing agile to new clients and different IT organizations is that the change management required can be very tough and has to be constantly and diligently applied. It would be great if every client was up for doing every project in an ‘pure’ agile manner, but that is not reality. What we can do though is gradually educate and show them what it means to be agile and why that is a good thing. The retrospectives are really key for everyone involved but the changes needed to refactor the teams and organization have to be embraced by everyone.

Scrum Issues And Organizational Change December 7, 2005

Posted by newyorkscot in Agile.
add a comment

We are working on quite a few client projects where Scrum is being implemented at the project and/or grassroots level in companies. In some cases, the “management” had got the concept of agile development and specifically, Scrum, pretty quickly and wanted to do it properly. In other cases, there was a willingness to try it, but need to mask it to upper management. (Both of these have approaches in their own rights, and probably worthy of further blog entries).In terms of client engagement management, I find that I spend most of my time making sure those who are doing it (grassroots, masked, or otherwise) really do follow the rules. This makes for some interesting engagement management, when you are not actually part of the client project team (ie you are a chicken with “special mentoring powers”). In the last week, we have dealt with the following issues:

  • Product Owners creating a Product Backlog with tasks mixed with features (so, get rid of the tasks)
  • Outside-company resources, who are supposed to be part of the Scrum team, breaking ranks from the team to do a whole lot of “cya” (an ongoing re-emphasizing of team dynamics and encouraging the team the provide the corrective action)
  • Product Owners being trying to make technical design decisions, masked as “I only want to make sure this will work going forward” (so, general beating up of the Product Owner and reinforcing the fact that the Owner only needs to know the “What” and not the “How” – also, “why should are we designing for something not in this sprint’s requirements again ?”.. pleasant amount of silence to that one !)
  • Teams trying to over-engineer the data gathering of tasks, estimates, actuals, work left, etc. (so, you only need to worry about the work (and time) you have left to get the Sprint completed)

The good news is that some of these cases come from newly formed Scrum teams which are only in their 2nd iteration, and that actually did a great job on many other levels first time around (one of our teams total work done was only 2% out from what they estimated). And they delivered, which is the most important thing.Based on our conversations with folks at our seminar last week, and with some of our current clients who are looking to expand out their “grassroots” agile development, it seems that we hit many issues very quickly in the adoption of agile in larger organizations or at the enterprise-level. Most of the issues, however, seem to be derived from the resistence to change that exists as a result of historical problems. Examples:

  • Analysis, development and QA teams are in different locations, so how do we have a cross-functional co-located Scrum team ? (There are a few ways around this, but the cause seems to be “well, if we are going to fail in development, we might as well do that cheaply by offshoring it”).
  • What does middle management do, when full-blown Scrum is adopted at the enterprise level ? Found some decent discussions here from the Scrum Alliance
  • How do we build an agile organization which is multi-faceted in terms of its functions and alignment (e.g. analysis, management, development, QA and aligned by line of business, domain and techonology expertise,) ? Some further discussions here
  • Existing development methodologies and minimum standards/expectations for documentation (CMM Level 2 in most cases). Many of the controls are in place because of the poor performance (people, process, etc) of the existing development methodologies. Becoming “light” on documentation and upfront “specification hell” is very tough for orgaizations to move away from. At the end of the day, there has to be some mutual agreement about ensuring the “right” level of documentation is left as a residual of the project, rather than being created upfront. Secret is to get them hooked on the delivery and wanting more of that …

Rant over for now …

Reliability And Innovation October 12, 2005

Posted by newyorkscot in Agile, Marketing.
add a comment

Jim Highsmith makes some interesting statements and recommendations in his book – this is a must-read as it also has many real-life anecdotes and other industry/acedemic references. The top-line summary is that any company in the marketplace has demands to continually innovate while facing pressures to reduce costs, and to deliver in a reliable manner. Agile Project Management (APM) provides the framework to do so.He discusses the difference between repeatability and reliability of execution of projects – he argues that the former is for production processes and the latter is for exploration processes (where requirements are uncertain). This means that rather than focusing on time, scope, budget of projects we should focus on time, vision, schedule. The difference here is that the project delivers / implements a valuable product (implemented vision) of what the customer actually wanted within the time & budget constraints, rather than a completely pre-specificed result.

Another interesting observation is the manner in which companies innovate products do not follow linear development paths, and have a high degree and frequency of market feedback (which in our case might actually mean our specific client who is paying for a the project!). Interaction with the end-user is key and too many people substituue interaction for documentation ("throw it over the wall at the development team" syndrome). [Separately, for those interested in technology & innovation, check out "The Innovator's Dilemma" by Clayton M. Christensen]There are many very interesting concepts in this book (particularly: Complexity and how working at "the edge of chaos" generates the most innovation; complex adaptive systems theory reshaping scientific and management thinking; adaptive versus compliance management approaches, amongst others). All said and done, his framework for APM does resemble a lot of what we have done for our clients and implement in our project teams (ie deliver customer value, iterative/feature-based delivery, technical excellence, pragmatic (simplistic?) approach. Jim provides the framework and concepts to provide more insight and control over how these are implemented and managed. Get this book, it is a worthy read for all those interested in not just APM, but in general control, systems, and organizational theories, etc

Scrum Certification September 19, 2005

Posted by newyorkscot in Agile.
add a comment

I attended the 2-day Scrum Master Certification course in Boston on Sep 22-23. Overall this was an excellent course both as a detailed course on how Scrum works and, just as importantly, the subtleties and application of Scrum as an approach to management in general. Ken Schwaber and Jeff Sutherland were both excellent in portraying the history, philosophy and workings of Scrum and the nuances of how to make it work.

There were a number of key takeaways for me, other than the mechanics of the Scrum Process.

The importance of trust, candor and honesty cannot be understated. The course demonstrated how too easy is it to be overly agreeable with clients and that the hard facts are what they need to hear. Building trust is about delievering the good and the bad news in terms the clients understand but also ensuring that all commitments are actually deliverable from the team's perspective. Often what people say and what they think or mean are not necessarily the same thing

Scrum is also a philosphy in how to get the maximuim performance from people through self-organization. The social interactions of people are at the key to the whole success of Scrum and when done correctly, the Scrum team will evolve and organize itself very quickly into a very high performance team delivering high quality deliverables in short timeframes. Internal reflection and accountability within one's own team drives out inefficiency and increases the ability to make decisions that are focused on delivery.

Scrum can be applied to anything we do in life such as IT projects, management of companies, marketing, product development, and even your own personal life ! Scrum is a simple lightweight process but its application requires a lot of common sense. It removes impediments, focuses on what CAN be done, provide continuous feedback and therefore is a continuous quality improvement process. Again, all based on candor and honesty.

As the course got into the implementation of Scrum to real life situations, there were many examples and exercises to demonstrate the approach required to roll out Scrum. In some cases, the adoption has to be at the grass-roots level whereby a team executes a Scrum process internally but masks this from the traditional management by showing what the mgt team thinks it needs to see. Gradually, the tools and results of Scrum are introduced and actually become the things management realizes it actually wants to see (e.g. burndown charts, delta backlogs, etc).

In other cases, the top-down approach can be implemented in terms of a) adopting Scrum across the board, which is very difficult to do, or b) as a new way of managing the organization itself. In general, the best adoption curve comes from trying Scrum a few times to get the hang of it and to see how the organization can the use it the best.

For me, it really forces management teams to focus by making people accountable for getting things done. If things are not being done, then the team will very quickly realize either the impediments, or what type of people they have on the team! Also, the course demonstrated the importance of cross-functional teams to ensure that all aspcts of a "product" are dealt with during its development in real-time rather than the "over-the-wall" approach to waterfall approaches.

The Scrum Master's role can be challenging in that they have no authority and need to rely on strong people skills to facilitate the process of self-organization. This can be very difficult to achieve particularly under scenarios where there are tough people issues to deal both internal to the team as well as with clients. For IT projects, it will be a rare person that will be a great Scrum Master as (ideally) they need a strong technical background, great client skills, and strong people skills. The course highlighted the "matriarchial" nature (or nurture!) of bringing the best out in people by the strict discipline of letting teams learn on their own but with guidance in a manner that is not "command and control" which most project managers use today.

I thought the performance measurements and estimating sections of the course to be very good as they really provide real-time transparency on how well the team is performing within a sprint and across multiple sprints. The beauty of the techniques is that they can adapt to changing requirements very easily, and the team has multiple ways of controlling its velocity and what it can deliver in any given sprint — and it MUST deliver something every sprint.

By focusing on one sprint at a time, and the resulting decomposition of tasks that occur at the planning stage for that sprint (up to 40% more effort being needed to be allocated above original estimates), it really brought home how bad traditional project management, waterfall and other prescriptive approaches are in dealing software projects as they continuously change.

Accordingly, there was some discussion about the definition of "Done". When is a product Done ? Clearly, this is something that will vary by project, product and organization.

Ultimately, once a Scrum team realizes how autonomous and self-sufficient it is being allowed to be, the natural dynamics of social interaction really kicks in, and they are off to the races. Once clients see how well this team delivers, then there is no looking back ..