Risky Business

NEW BLOG

2006-08-30T17:36:00.000-04:00

I HAVE MOVED BLOG TO:

http://newyorkscot.wordpress.com

I NOW WORK FOR Lab49

See you there.
Cheers,
Ross.

Moving On ...

2006-05-03T12:13:00.000-04:00

In two ways:

1. Time to move onto new blogging pastures. I like a bunch of the functionality (templates, widgets, sidebar configuration and other tools) over at Wordpresss. New blog is here.

2. I am leaving my current employer, Finetix for pastures new. More details over on the new blog.

It's been emotional.
Cheers,
Ross.

Wembley Retrospective

2006-03-31T12:44:00.000-05:00

Saw this ...... sound familiar ?

Glacial Methodology

2006-03-15T09:48:00.000-05:00

Here ... mildly amusing

Waterfall 2006

2006-01-27T14:47:00.000-05:00

Check this out ...

Agile Team Dynamics II

2006-01-27T09:59:00.000-05:00

[REFACTORED: I have updated this post to answer some of the specific questions I received. Thanks also for the many comments posted - but since there was an increasing number of inappropriate postings, especially foul language, I am moderating these now.]

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 finetix 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

2005-12-07T15:05:00.000-05:00

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)
Non-Finetix 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 ...

Flock And Web 2.0

2005-12-01T21:16:00.000-05:00

Anyone checked Flock out yet ? Looks like it already has some cool interactive features for web-browsing and publishing, ie a 2-way browser. Intelligent blogging access and Flickr integration seem to be the main things up and running so far..

Also, saw this fairly comprehensive article which has some history/analysis on Web 2.0

Blue Gene/L Supercomputer

2005-10-28T15:21:00.000-04:00

Saw this today - reminded me of the '90s when we thought we were doing pretty well when we went from running 6 RS6000 machines to calculate sensitivities on a global portfolio of FX derivatives to running some exotic books on a Cray machine at the Minnesota Supercomputer Center. Processing power has moved on a shade....

Still Running.....sad, but true

2005-10-28T12:02:00.000-04:00

Client: Let's build a credit risk calculation engine for regulatory capital reporting purposes. We know this will take a lot of analysis and design, together with 12 months of development. We have preselected Hibernate as the technology of choice to help us with access to the Oracle DB. We know that we will have to crunch over 2 million transactions a day on a batch basis where we will need to load reference data and calculate credit exposures for every transaction. Remember also that we have just completed an optimized batch calculation architecture before starting this project that can do over 2million transactions in less than an hour.

Finetix: What will you do in terms of :

1) Leveraging existing architecture

a) Definitely Use It
b) Do some analysis and figure out the efficiencies of re-use and gaps
c) No. New project. Let's build new infrastructure from scratch.

2) Ensuring that your system performs appropriately ?

a) Let's collectively review the architecture for performance purposes, once we have designed it (and maybe even build a prototype?)
b) Let someone else figure out we have not designed this properly for performance at some point during the development process, and then ignore them.
c) Decide to wait until we have finished coding and get to SIT/UAT to performance test whatever we have at that point.

Client Answer: ? 1(c) and 2(b) and (c).

Client Results: a 68 (!) hour process to crunch 600k transactions, compared to doing over 2million in 1 hour. The cause ? The use of cursors that go row by row through the data in Java and query the database for each one. Chances of quick fix - none.

Nice work, guys.

New Methodology... brilliant !

2005-10-28T11:50:00.000-04:00

The new (or old?) way of tackling tough projects, check out the new way: JDFI .

Additional momentum provided by Matt.

Certified

2005-10-11T17:19:00.000-04:00

A few of us certified Scrum Masters have been added to the list here, on Ken Schwaber's website.

Scrum Master Certification

2005-09-29T10:10:00.000-04:00

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

The Risk Mgt View Of Scrum

2005-09-16T14:37:00.000-04:00

Been reading 'Agile Software Development with Scrum' by Ken Schwaber, Mike Beedle, and saw these great risk factors Scrum specifically addresses (Section 6.3):

Risk of not pleasing the customer: customer gets to see the product on a continuous basis
Risk of not completing all functionality: functionality is developed in a prioritized way through Sprints, ie high priority functionality is delivered, and only low priority is missed
Risk of poor estimating and planning: Daily scrums provides small estimates that are tracked within a Daily Scrum cycle and through the invariant set of Product Backlog assigned to the Sprint cycle.
Risk of not resolving issues promptly: Burden of proof on management by requiring daily active management. In Scrum, role of management is bi-directional so that mgt reports to the staff on how it is resolving issues during Daily Scrum.
Risk of not being able to complete the development cycle: Scrum ensures that there aren't any major problems with the development cycle by delivering working software every Sprint. This forces issues to be dealt with.
Risk of taking on too much work and changing expectations: Scrum disallows any changes in the Product Backlog associated with a Sprint so that the team feels their goal is respected and the customer has clear expectations.

Blogsphere Guide

2005-08-16T12:53:00.000-04:00

I found this article while looking at the services Ogilvy (the ad, marketing, PR, etc agency) provides. It discusses how the entire blogsphere (blogs, wikis, podcasts, etc) should (or could) be used for formal corporate marketing, and some of the guiding principles for their use.

Reliability and Innovation

2005-08-04T08:22:00.000-04:00

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

Agile PM tools - review

2005-08-03T11:22:00.000-04:00

Colleague of mine if currently doing some reviews on some Agile PM tools..

Project Risk Management Tools

2005-08-02T13:33:00.000-04:00

I am interested in seeing what people are using out there for project and risk management tools in Agile projects -- other than excel, MS Project, etc. Specifically, I am interested in hearing about people's experience with XPlanner and its relative strengths/weaknesses. Found this review. What else are people using ?

I am also waiting to see what the Agile Project Leadership Network comes up with in terms of specific tools and strategies. Their principles sound fine to me, but lets see some details, guys ! (Do you need to be a member to see everything they are discussing ?). I did see this though in their website: a comparison of CMMI and their Declaration of Interdependence.

Here is another interesting article discussing PERT, CPM and Agile Project Management..

Update: based on the comment, I also found this great set of resource on agile project management on Rally's website.

Client Meeting -- Another Risk Mgt Sell

2005-08-02T10:37:00.000-04:00

A couple of us went to see a prospective client yesterday. To cut a rather long story short, they need a team of real heavy duty technical talent to build out their application and technical infrastructure since their current consulting firm does not have the wherewithall to get the job done.

We met with the senior manager who asked some obvious but pertinent questions. How do we structure projects in terms of risk and project management ? What controls do we put in place before and during a project ? How do we work with other incumbent groups in an organization, whether they are employees or other consultants ? How do we incentivize and motivate our staff to get the project done ? Many of these are general questions we take care of through engagement and relationship managent, project-specific structures, employee benefits packages, as well as team-based get-togethers, etc.

Ultimately though, once again it comes down to how we mitigate risk (particularly for a new client we have not worked with before): put a plan together for a series of quick hits of delivering functionality, demonstrate our value and potential, gain quick feedback, provide quality rather than quantity (and they will pay for quality), regular communication at the executive and project level, etc. And guess what kind of approach provides that .... ?!

Also, buyers of products and services tend to think of the things in a different way than those doing the selling or execution, so the message and approach of a project needs to bridge that gap. I have mentioned some ideas before on this. Here also. However, one can only address most of buyer's objections and issues so far. There is a philosophical difference in mindset in how different people sometimes think of these projects (ie CFO vs PM vs vendor). Fundamentally, how can you ever 100% guarantee scope, time and budget to any client without something giving and breaking the financial vaiability of the project ? You can't. So therefore don't even bother trying to figure that out.

It is about trust, shared responsbility and risk mgt. (see this on trust as well). If you can't get the first two, forget it. Problems, dependencies and issues happen on every project and sometime unexpectedly -- your solution/ approach needs to expect and embrace this.

Intro to Basel II (Credit Risk)

2005-07-27T16:58:00.000-04:00

Found this article as a starting point on understanding Basel II, courtesy of wikipedia.

Agile 2005 Conference

2005-07-26T09:52:00.000-04:00

Two of my colleagues, DLG and DC, are attending the Agile 2005 conference in Denver. Check out their notes and thoughts on the sessions.

How to Fail with RUP

2005-07-21T10:55:00.000-04:00

Check this out - decent explanation of what people do wrong with RUP.

Flashback: Rolls-Royce Aerospace

2005-07-20T18:13:00.000-04:00

I was really glad to see that Rolls-Royce Aerospace recently announced plans to build a new overhaul plant in Scotland. I used to work at this specialist plant while studying Aerospace Engineering at university. At that time, post cold-war, the defence industry was weakening and many RR jobs were being threatened (RR builds a lot of defence engines, like the one used in the Harrier "jump-jet"). This was when I decided to get into IT and the Financial Services industry, and specifically to join JPMC in London, so RR really was the first step to where I am today.

Personally, this is/was a cool plant to work in -- you got to see all the leading civil and defence engines, hands-on, and got to see how they test them (yes, the old throw frozen chicken at it story - no-one seemed to point out the fact that a frozen chicken, dead or alive, cannot fly at 37,000 ft, or sea level for that metter!). Btw -- this is the engine I was most inolved in - a joint venture with Pratt & Whitney, and we had to redesign the fuel system to make it more environmentally friendly.

From a business perspective, this is an interesting move on RR's part. In the early 90s everything was being moved south and consolidated as RR tried to save money, improve efficiencies, etc. That fact that this plant is going to be replaced/upgraded to a new plant, is fantastic news and a true testament to what they do there. At the time, it was all doom and gloom and the risks associated with being able to have a career there influenced my decisions then, and where I am now, personally and professionally. Brilliant news for RR and the local economy - I wish them all the best.

Addictive clients

2005-07-20T16:50:00.000-04:00

Our clients have addictive personalities. The number of times we have put people into clients on projects and can't get them moved on to other project is crazy.

The problem is as follows: a) plain and simple: our people are the best at what they do, and have a habit of blowing their clients away from a domain and technical perspective, b) SOWs come and go, and we all know that scope changes, schedules change, etc etc, so keeping SOWs in sync with reality is a tough job, and obtaining and keeping good people is a tough thing to do (once they have them, that's it in their minds).

It is the nature and culture of our people that they want to work on new and interesting projects (and so do we!), plus we want them to lead up new client and project opportunties.

So, how do you not upset your client when either the SOW expiry has come and gone and you have had other plans for your people, or you want to rotate them in a pro-active manner ?

Balancing your supply (sales pipeline) and demand (current staff allocation, bench and people you need to recruit) is the obvious thing, but reality is not that simple. I have always said look after your current clients before your future clients, and there are things you can do to actively plan and work with your clients. However, my biggest risk is always that clients DO get addicted to our people and sometimes you have to adopt the band-aid approach -- rip it off, let it sting, then get on with life.

Technology Marketing

2005-07-20T16:01:00.000-04:00

As we were preparing some new marketing messages and ideas for our sales team, we ran into an interesting issue -- we actually did not have the exact same view on what we did in life as a company. We have been very successful at executing our projects for clients over the last ten years, are pretty unique in what we do (building specialist business and technical solutions for capital markets clients), and we all have a general idea of what that has been. The problem is really how we actually articulate that at a formal but granular level ?

I ran an emperical excercise (basic marketing 101 stuff). I asked the mgt to answer the following questions:

Who are we ?
What do we do ?
How do we do it ?
Who do we do it for ?
What is our value-add to clients ?

The results were very interesting -- we did all agree on the general type of work we perform, but the way we communicated it was inconsistent, yet enlightening, but not surprising. This exercise validated the fact that we have never formally sat down and answered these questions as part of a formal communication plan (mainly because we have never formally done marketing since most of our worok has come through relationships and reputation - imagine we we actually actively market ourselves ?!!). It is clear that we all represent the company differently depending on the situation (not a bad thing), but we don't have the "elevator pitch" nailed. What was interesting was some people came up with some creative (and true!) ways of telling the story which we were then able to use in new ways of communicating our service offering(s).

One other issue it raised was: as a professional services company, how do you formally structure your service offerings ? We have a particular challenge in that we provide a range of specialist skills and services to clients through a project-based approach. However, the reality is that the makeup of the project varies by client and domain. Sometimes the client wants us for our Capital Markets domain experience, sometimes for our technical expertise, and sometime because of our approach/philosophy to projects, sometimes for any or all of the above. The challenge is to stay focused and differentiated from the competition, while also providing a relatively broad level of appeal to prospective buyers on paper. The good news is that once in front of a client we have a really high success rate because we fundamentally understand our clients and know how to "situationally sell"

I guess the acid test will be if we can't tell our own sales guys what our message is, they have no chance of telling our prospective clients ... stay tuned as we sort it all out..