NEW BLOG

I HAVE MOVED BLOG TO:

http://newyorkscot.wordpress.com

I NOW WORK FOR Lab49

See you there.
Cheers,
Ross.

Moving On ...

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

Saw this ...... sound familiar ?

Glacial Methodology

Here ... mildly amusing

Waterfall 2006

Check this out ...

Agile Team Dynamics II

[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

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

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

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

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 !

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

Additional momentum provided by Matt.

Certified

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

Scrum Master Certification

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

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

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

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

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

Project Risk Management Tools

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

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)

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

Agile 2005 Conference

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

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

Flashback: Rolls-Royce Aerospace

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

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

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

Selling Agile -- A Risk Mgt Sell

I always get asked questions about selling agile projects to clients, and in particular how do we deal with large programs (with all their artificial due dates, and door-stops of func spec), vendor mgt negotiations/objections, and the old CFO question: "how much will it cost for the final product".

The problem in actually dealing with these folks is that they fundamentally don't recognise their own issues/problems/weaknesses, and don't understand the alternatives. Specific issues include:

• Their own time to delivery is very long
• They only have one shot at getting it right
• The users WILL change their minds, and/or there WILL be ambiguities in specs
• The period for ROI analysis is too long as the sheer number of resources, dependencies, risks, issues, etc on the investment side becomes complex to measure, against a highly uncertain measurement of results and thus return.
• They currently don't have a good way of measuring product quality.

Throw into this boiling pot, their desire to fixed price the project and/or require payment on deliverables, and already we get into a never-ending cycle of negotiation. For some other details check out this guy's blog post.

So, let's try to put some simple meaningful and business-savvy ideas forward to the person on the other side of the table:

• What if the user provides the direction in what we build in any given 'timeboxed' period (oh let's say, 30 days?) , and we agree to a set of deliverables in that period?
• And, what if we get paid for the work we did on each 30-day period, providing we did what we said we would?
• And, what if this results in a series of fixed cost schedules ?
• And, what if everytime we deliver what we say, it works in production ?

Then,

• Wouldn't that ensure the users actually gets what they want ?
• Wouldn't that mean that the worst downside risk, is what happens in any 30-day period, resulting in the ability to calculate a series and aggregate ROI numbers ?
• Wouldn't that mean that the product quality is controlled throughout the project ?
• Wouldn't that give vendor mgt and a CFO what they want in terms of risk mgt, controlled costs ?

Incremental & Iterative Development Risk Mitigation

Some thoughts on where incremental & iterative development (IID) methods mitigate risks not provided by a waterfall approach:

• Risk-driven iterative development forces tackling the most complex and riskiest problems first.
• IID requires testing early on (even before coding), with tests being improved over iterations.
• Early visibility for clients into the interim and target product and therefore better feedback mechanisms to refine the functionality/capability. This is forced by continuous and formalized input and presence of clients during development.
• Performance risk profile of the application is improved by delivering tested software frequently.

Other thing I have noticed recently (not us!) is people building up a door stops' worth of functional specifications, and then looking to do agile development against that. Amatuers.

2-D Risk Maps

In James Lam's Enterprise Risk Management book, there are some general approaches to Operational Risk Management as well as brief discussions on some of the specific techniques on how to assess and control risks. One particular approach is that of developing 2-D Risk Maps whereby a general risk assessment is treated with the application of relative risk rankings (with respect to probability and severity). Additionally, he discusses risk indicators and performance triggers that get factored into the "dashboard"

I can think of a number of examples of the indicators and triggers (e.g. 99.97/8/9% uptime of a production application or piece of hardware, etc). But, I would love to see some specific examples of these Risk Maps for an bank's application environment as I think this could be a rather tough thing to create given the diversity and complexity of the enterprise. Presumably, the severity ranking would include the criticality of the application in general, impact of certain functions/information not being available, and the knock-on (chain) effects. As for probability, I would imagine that it is more of a combination of some emperical data (ie knowledge of existing problematic systems) and a some finger-waving guestimates.

Corporate Taxonomy

Not everyone sees or thinks of things in the same way, and this has become alarmingly obvious when a group of colleagues and others discuss the Agile umbrella of IT methodologies. This is a fundamental risk we need to deal with in order to demonstrate our corporate culture, professional excellence, consistent project approach, and platform for marketing to clients.

In this case, Agile Development, not only are we talking about a set of methodologies under an overarching set of principles, each method has its respective theoretical pros and cons as well as what the professional and individual experiences of our staff have been, with any one or more approaches. No doubt there will be divergent opinions, but that is why we need a core position that we can then at least tweak on a project basis. In our business, experience is everything.

One avenue to aid this problem, might be to have a corporate taxonomy for our company that we all agree on. This would include the definition of terms, how techniques/process relate to one another (or not), and any crossovers. The natural extension would then to be to draw out the "best practices" or some working model that we believe would form the core approach for our company, given the type of projects we typcially undertake in Capital Markets.

Based on other feedback, it sounds like we need a hybrid model that also factors in real client needs as well as the best blended approach that might have a chance of *actually* working on client sites. Either way, we need to have a common language and "corporate view"that we can all adhere to before, during and after client projects. Perhaps a corporate Wiki is what we need.

Fixed Price: A Naive Approach

It would seem that most of the larger financial institutions are adopting one of the following models for outsourcing IT project work:

• Pure Staff Supplementation - get a body as cheap as you can to work under the client PM as part of the team
• Fixed Price (Cost) Project Work - (theoretically) fixed cost, set scope, set time.
• Offshore - the staff supplementation approach on steroids with some multi-location overhead thrown in for good measure (yes, I am a cynic)

Some are still permitting T&M project work as well. From a banks' perspective, I understand that minimizing / locking in / capping costs is important. However, how many of these company's business,IT or vendor management understand the constraints and risks imposed on the vendor by some of their preferred approaches ?

The three axis of classic systems development management are of course scope, time, budget, with the assumption that if you lock 2 of these, you set the 3rd. Often the time is set by business needs and their wants/needs without due consideration for the poor IT guys actually doing the work. Budgets are set, pretty much, and so the price constraints are pushed to the vendor. But do they flex on the scope.. I think not. From a vendor's perspective, unless you are building a space shuttle, the scope simply is never bolted to the floor -- and even the best specification can create ambiguities, or misrepresent what is going to be built .

All of these constraints that a vendor faces can be alleviated through a T&M approach, or by a more agile approach to project execution. (I am not pitching Agile here, although we all know that iterative/RAD/Agile approaches can certainly be the best way of building out functionality to maximize user satisfaction - where appropriate).

The real risk here is quality of delivery and the adversarial relationship that can occur when clients expect vendors to deliver a set scope in a fixed timeframe and/or budget. The legalese are a nightmare. The relationships can sour and spoil reputations, and the quality of the product can be terrible through corners being cut, functionality being descoped (not always to plan), and customer service can go through the floor.. all of which costs more money directly or indirectly.

Mature relationship, project and risk management are essential (always, no matter the project), but real life is not always that cookie cutter.

Perception is everything

True story. We have been working for a fixed income trading desk that officially (from a management's perspective) uses a homegrown processing system for its positions, P&L, and back office processing. This system can provide intra-day positions and P&L upon request, but the traders have never (meaning over years) believed the numbers this system produces and so have not used it. Worst still, they **guess** their positions and P&L during and at the end of the day, and can often be $0-1mm out in their guesses.

We have been working on a number of projects for this business where are are doing a mix of RAD and tactical/prototypes for some new risk mgt tools for the traders. One of these prototypes pulls together a bunch of intra-day data from various sources, including the above mentioned system, does some aggregation and provides a rich and flexible front-end for position and P&L tracking (the server and client side is .NET, btw).

These traders think this tool is the best thing since sliced bread and think it is much better and more accurate than the old system they are/were supposed to use. How ridiculous is this ? Can you imagine a multi-million dollar a day business being run by people guessing their P&L, let alone thinking that the new sytem is better than the one they despise ...!!

PS. Not a bad argument for Agile development though, where users get what they want ..

An Insider's View on Agile

This is from someone inside our client base who has also tried to sell & manage Agile projects....

The issue with selling (and managing) Agile projects is maintaining the balance between rapid delivery and controls. Traditional projects that businesses are used to following expect a roadmap, milestone dates, dependency dates and anticipated ends with expected functionality. With Agile methodologies, requirements are developed as you go and the end state is less predictable. Keys to success include tightly managing expectations and setting guidelines for each iteration. Selling these types of programs are difficult because they don't fit within the traditional framework - if you can walk through a project lifecycle and build the predictability by setting tight guidelines for estimations, time spent on an iteration, level of detail spent on each component at any given time, building a working end-to-end system albeit "rough" functionality in the first few iterations I think you can demonstrate the benefits of the methodology and mitigate the risks.

Also, large companies and large programs will worry about the forecasting of key dependencies on integration points with other systems. You will need to accout for that as well.

In the end you will create a hybrid traditional/Agile methodology to enable you to gain the speed and agility of rapid iterations with the controls, planning and forethough of integration.

Situational Leadership

colleague of mine sent this link about styles of management required to run agile projects effectively .. interested to get some opinions on this ..

http://www.mountaingoatsoftware.com/articles/SituationalLeadership.pdf

Selling Agile or Agile Selling ?

I suspect this will be the first of many entries here, so here goes with the can of worms: How do you sell an agile approach to delivering projects, factoring in the needs/issues/barriers of the folks in the client: PMs, CTOs, vendor mgt, legal, CFOs ?

We can create the nice glossies and presentations talking about this, that and the other benefit of agile methodologies (whichever one or combination you prefer), but there is more to it than this.

My take on it is more to do with the classic 'Solution Selling' approach: block & tackle question model whereby there are three main lines of questioning : diagnose, explore impact and visualize capabilities, each with a subset series of questions: open, control, confirm... (btw - this Solution Selling is probably another blog entry for the future). The point is that you need to understand the business problem and pain (or latent pain), and then apply your judgement (and agility) as to how you can solve their problem quickly and effectively. I think this is a pragmatic and experiential sell - you need to know your stuff, but be able to iteratively work out the right approach for the problem - sound familiar ?

Others have blogged about the legal side of things, which I think requires a shifting of the mindset on the side of the clients' legal/vendor mgt. It almost like you have to disprove the status quo and show that they business NEVER gets it right first time, and that quick meaningful deliverables (production quality) is actually what the business wants. Some further thoughts from the 'Agile Champion' are here.

As I said, this was just to open up the can of worms. Any first hand experience of others in selling agile approaches to non-buyers would be appreciated ...

Attrition from Client projects

Attrition happens -- I have no problem with it and we need to deal with it as a course of doing business. Whether it is for more money, better opportunity, change in career direction, family demands, whatever, it is all cool with me.

What really gets my goat up, is when people agree on a start date with a new employer, but fail to agree on the last date with their current employer. Two weeks notice is standard issue in the US, 4 weeks in the UK, but for goodness sake please assume that that's what your employer and client expect from you, not whatever you think you can get away with.

What is intruiging to me is when I have to tell a client one of our people has quit, and the notice is less than the contractual obligation (and remember we as a vendor have our own obligations to the client), the leaving party actually thinks they have done the right thing by everyone and will say "..it is a small world and I am sure we will work together again sometime .. I really like you guys ..". Yeah, right. They have in one fell swoop just nicely torched a bridge or four, and will never be employed again by us or our client. Grow up, please.

From a risk mgt perspective, there are some obvious negatives to this and only so much you can do (other than having a bench!). On the positive, I have found there is opportunity to relate to the clients' heartache and to possibly re-jig a few things around to our mutual benefit.

Agile: Frequency = Currency

Was talking to our Chief Architect (see netflings ) this morning about his experience with what well executed agile projects can do for you and your client IT manager. Showing the business that your quick hits add value and iterating to what they actually want, buys you a lot of credibility and therefore currency in dealings with them later on .. either to get more busines from them, or to use your credits for when you do mess things up (which you will at some point!).

The interesting thing about our CA's project is that is was done with a small team of .NET developers working along side the traders of a hedge fund who are big into credit derivatives. Instead of buying an off the shelf product like JRisk, this team delivered with a high frequency and thus very low risk (once they got over the initial hump of getting their feet under the table)..

Scoping Problems

Another rats' nest of a topic ..

Banks are horrible at scoping their needs, so why don't they wake up and do something about it ? Too easy a question to ask, I guess. Part of it is management's incompetence, some of it is crap BAs, indecisive business users, the list goes on.

This week though was another good example where we spent 6 weeks working on an RFQ to define a scope of work (in general terms of course), and then get our approach and shop in order. We spent a lot of time on the governance and risk mgt side of things ensuring we got the client dependencies & responsibilities outlined (first cut until we actually start the project, of course). One of those dependencies was getting the main set of use cases done and any other requirements before we could do our thing. Literally, on the first day of the project our project lead tells me "the guy doing the use cases is working on something else next week, so won't be done until then". First friggin' day. Then next day "we [the client] have some delays, we want your team to help out on another project..." Time to bolt down the doors and stick to our plan, I say.

I know this is a common thing in scope creep, etc, but these guys are just simply awful at it. My whole thing in doing this blog is because of the need for risk mgt everywhere and this is one of the prime culprits. Any waterfall based methodology is simply flawed (as many would atest to), but it is our duty as consultants to bring them around to a new way of thinking in terms of either sticking to a plan (meaning both some upward management and introducing them to an agile plan that can adapt to changes in not only scope but timing of tasks), or saying "NO", or "games a bogey, let's be a staff supplementation company" .. first two sound good to me..

Project Measurement and Control

How horrible are people at managing projects ? Create a plan, let it gather some dust while you do something different , then bin it. This is one of the biggest problems today in IT.

One thing I want to do is to derive some risk management best practices for the types of projects we tend to do in Capital Markets, based on some of the experience out in the marketplace for agile development and other alternate approaches. The other area I want to evolve is the role and experience of our project leads in these projects -- are they domain experts, converted PMs, upgraded BAs, maturing techies ..... ? Stay tuned on this one.

From a vendor's perspective, I have found that a formalized status meeting of both sides is key -- bi-weekly being a good balance between not intruding on people's time and staying on top of things. The focus is not so much on measurement and control (M&C), but on risk and issue management, as well as general performance feedback. A couple of main reasons, I see, for this: a) it is the client PM's job to do the M&C as well as our own team lead (in terms of his team's tasks), b) I have to trust my guys and not to micro-manage them (not my style anyway), and c) it is the big ticket items, politics and barriers that will screw the project, and not so much the minor implementation or functional details.

That said, too many times project-based consultants get treated like the staff-supplementation folks (and that's not just our people that feel this), resulting in the client PMs (micro) managing the tasks of our folks. This is an uphill battle, but a fight we need to stick to in order to ensure we don't get sucked down a rathole and away from the project in hand.

AD & Production environments at banks

One thing I have heard a lot of people talking about in the banks are the issues around shared production environments (yes, yes, dev environments as well, but I am talking about the stuff that loses businesses money in real-time). Recent gems include:

• real-time calculation engines, batch and process based applications, and web applications running in the same memory space on a single VM.
• distinct applications running on their own JVM, but communicating across a common messaging hub whereby a huge amount of Java objects are serialized/deserialized, taking up to 90% of the CPU cycles, with 10% being left for actual business functionality

How does this happen ? Is it bad architects ? Are there historical / evolutionary reasons ? Is it bad implementations of the design patterns (if there are any) ? A lot of "bubble diagrams" and no prototyping ? A bit of everything, I suspect. I understand when tactical systems become less-tactical and more entranched, bad things do happen. But on new builds ? Seriously, when these guys are putting together new component-based architectures (in one client now), how does this happen consistently? There is a fundamental problem with the way these organizations build even the most basic of production applications. Call it incompetance, lack of quality control, poor engineering talent, bad management, or whatever, it IS incredible...

Work In Production ....

I have developed a somewhat sick interest for how people screw things up. I have an (aerospace) engineering background, been in the IT development & management space, done the strategic marketing for technology companies, amongst a few other things, and have seen a lot of hackers, incompetants, prima donnas, and complete BS-ers. Along the way I have seen so many things that could have been avoided through relatively simple risk management and better governance over the decision making and development processes of projects (of course all with perfect 20/20 hindsight). All sides of running and servicing a business is risky, and always will be, but this blog is my humble views and random ramblings on what is going on at the moment in the corporate world. Think of it as the out-takes of work in production ....