Posts Tagged ‘Agile’

Being agile in a service based industry

Today I presented in our Intergen Wellington D&I mentoring session for the first time about agile development in a service based company. I think I have a really good story to tell but don’t think I articulated it as well I had hoped to.

I shall refrain myself from repeating what’s already been said succinctly in the slides.

Here are the slides in ppt Being agile in a service based industry


Microsoft Office 07 has been out for AGES and WordPress doesn’t even allow me to upload an .pptx file. That’s just not on!!!



Principles of agile development (1)

1. “Early and continuous delivery.”

Business processes are ever changing (even during the course of development) and sometimes customers don’t necessarily know what exactly they want out of the system till they see it in action. So it makes sense that the earlier and more frequent we involve customers in the process the quicker customers will be able to provide feedback to the development team, this ensures that the system in development will closely follow what the customers need and hence a high quality in the final product.

Martin carries on and says “We strive to continue to deliver systems of increasing functionality every few weeks. Customers may choose to put these systems into production…” This putting it to “Production” part makes me ponder, if the release cycle from development to production are as short as a matter of weeks, wouldn’t the team be spending a significant percentage of its time dealing with deployment? Database schema might be changed in between releases to production, a data migration need to happen each time a new release comes out and put to production. The system maybe composed of different components to be deployed to different (sometimes virtual) environments, it can be a very tedious process if not managed well and/or not automated. There could be so much work involved in making each release to production and this may or may not justify making it to production at all.

2. “Welcome changing requirements.”

I remember from an interview that Ron Jacobs did with Martin Fowler, Fowler said something along the line of “During software development, change requirement would be the most painful things, therefore we should do it more and often.” I was like huh? Now I start to realise what he really means; systems we develop are there to create value for businesses and should follow business requirement and processes as closely as possible, we welcome requirement of changes because they close the discrepancies between the true business processes at the time and the processes the system is implementing and therefore bringing the system more aligned with the business.

However, in the real world almost all the clients (the ones I’ve had experiences with anyway) would want a fixed budget, fixed timeframe and fixed scope. They do understand but refuse to accept that out of the above three dimensions if two are fixed the third must be variable. However this is somewhat understandable, in a business environment, no one wants to commit to a contract that contains uncertainties especially surrounds what needs done, when it needs done by and how much it going to cost (the above mentioned three dimensions). In the services industry, the clients (the ones with the $) tend to dictate the contract (a.k.a. arm length transaction), in which the above three dimensions are specified. This makes it really hard to abide by this “Welcome changing requirements” agile principle without running at a loss to the service provider. It’s like keeping blowing up a balloon without worrying about if it’s going to burst at some point. Inevitably, there is always going to be a trade off, development team will have no option but to cut corners somewhere and it could well be the quality of the product; code reviews, infrastructural refactoring that’s deemed appropriate over time, sometimes even testing etc. So what’s the solution here? Should we only service cash cow clients and have unfixed deadlines, or do our team developers have to live on coffee, Vs or redbulls and slave past mid night every day? Or both the clients and we have to take a step back and compromise. What’s your thought on this?

3.”Delivering documents and plans are not counted true delivery.”

I think this is arguable. Ultimately, it’s the working software that delivers true business values (if at all). We should deliver software early and frequently. There is no point of slapping the clients with bundles of documents without accompanying the working software since there is no values creation whatsoever. However, documents can contribute to business values indirectly when accompanying working software. Various forms of UML diagrams (if kept up to date) can be a very good set of tools to capture businesses process that the software is implementing and a good means of communication amongst technical, business people or any stakeholders for that matter. But documents can be very easily over prepared, documents shall only be written up to the granularity that’s required by its use and purpose. There is no point of documenting each and every methods signatures in a class diagram if it’s only designed to be used amongst architects to communicate the overall architecture of the system.

Martin’s first law of documentation; produce no document unless its need is immediate and significant.


The Agile Alliance Manifesto

These are some truly mind blowing, eye opening rules (to a newbie anyway)… here are some extracts from the book (Sorry about the mass copying & pasting, I just had to include each and every word of it… they are simply well meant.)

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to changes over following a plan

Here are some points from the book I think are really helpful in understanding these rules…

1. Individuals and Interactions over Processes and Tools.

“People are the most important ingredient of success. Principles, patterns and practices are important, but it’s the people who make them work. We cannot manage teams of developers as if they were systems made up of components driven by a process, plug-replaceable programming units.

A strong player is not necessarily an ace programmer. A strong player may be an average programmer but someone who works well with others. Working well with others, communicating and interacting is more important than raw programming talent.

Tools can be overemphasized. An overabundance of big, unwieldy tools is just as bad as a lack of tools. Don’t assume that you’ve outgrowns a tool until you’ve tried it and found that you can’t use it. Don’t assume that bigger and better tools will automatically help you do better. Often, they hinder more than they help.

Building the team is more important that building the environment.”

2. Working software over comprehensive documentation.

“Software without documentation is a disaster, however, too much documentation is worse than too little. Huge software documentations take a long time to produce and even more time to keep in sync with the code. If they are not kept in sync, they become a significant source of misdirection.

It’s always a good idea to write and maintain a short rationale and structure document that discuss the overall design rationale and only the highest-level structures in the system.

If all we have is a short rationale and structure document, how do we train new team members about the system? The two documents that are the best at transferring information to new team members are the code and the team. It’s difficult to extract rationale and intent from the code, but it’s the only unambiguous source of information. The team holds ever-changing road-map of the system in its members’ heads. The fastest and most efficient way to put that road map down on paper and transfer it to others is through human-to-human interaction.

Martin’s First Law of Documentation

Produce no document unless its need is immediate and significant.”

3. Customers collaboration over contract negotiation.

“A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed. In most cases, the terms it specifies become meaningless long before the project is complete, sometimes even long before the contract is signed. The best contracts are those that governs the way the development team and the customer will work together.”

Software cannot be ordered like a commodity. You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price.

It’s tempting for company managers to tell their development staff what their needs are and then expect that staff to go away for a while with a system that satisfies those needs. But this mode of operation leads to poor quality and failure.”

Martin carries on to describe a A large, multi-year, half-million-line project that he has had;

“The development team, were paid a relatively low monthly rate. Large payouts were made when the team delivered certain large blocks of functionality. Those blocks were not specified in detail by the contact. Rather, the contract stated that the payout would be made for a block when the block passed the customer’s acceptance test. The details of those acceptance tests were not specified in the contract.

During the course of the project, the team worked very closely with the customer. It released the software almost every Friday. By Monday or Tuesday of the following week, the customer had a list of changes for the team to put into the software. The team prioritized those changes together and then scheduled them into subsequent weeks. The customer worked so closely with the team that acceptance tests were never an issue. The customer knew when a block of functionality satisfied their needs, because they watched it evolve from week to week.

The requirements for this project were in a continual state of flux. Major changes were not uncommon. Whole blocks of functionality were removed and others inserted. And yet the contract, and the project survived and succeeded.

The key to this success was the intense collaboration with the customer and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost.

This is a very succinct account of how the project went on, it just makes sense to me.We talk about early customer involvement in the project all the time. But, seldom, people talk about how this should be done, and this accounts explains it well.

I do have a few of doubts about it though,

A release cycle of one week for a “large, multi-year, million line project” seems a bit too tight to me. Thinking of shipping code from development to testing then to customers within a week, it’s just unrealistic for the size of the project as it sounds. Unless the functionalities were broken down to really small pieces and only a few of these pieces are included in one cycle. Or they just had LOTS of man power that can turn around a large chuck of functionalities within a matter of a week. What’s your thought on this?

Another concern is; If this “a contract that specifies the cost, schedule and requirement is fundamentally flawed. The requirements for this project were in a continual state of flux throughout the course of the project.” claims hold, doesn’t it sound like entering a Marathon race without knowing how long the entire course is and what the route condition is like? Or building a highway between two random coordinates in the Amazon without knowing what exactly are in between these two points? i.e.; The customer would have no way of budgeting for a project’s cost and scheduling for it, and just how many customers can do this??? Certainly not the corporates with a responsible CFO. What do you think?

Lastly, what would this “relatively low monthly rate” cover? All the man power (i.e.; chargeable hours) for that month? If so, what is in this “large pay out when when a major functionalities are delivered”?

4. Responding to change over following a plan.

“The ability to response to change often determines the success or failure of a software project. The course of software project cannot be planned very far into the future for two reasons. First, requirements WILL change. Second, development team aren’t good at estimating how long things will take to develop, especially for far-into-the-future tasks.

It is tempting for novice managers to create and tape to the wall a nice PERT or Gantt char of the whole project. They may feel that this chart gives them control over the project. Cross out tasks that are completed, react to any discrepancies in schedule. But in reality, structure of the chart degrades over time as the team gains knowledge about the system and the customer gains knowledge about the team’s needs. Certain tasks on the chart will become unnecessary, Other tasks will be discovered and will need to be added. The plan will undergo changes in shape, not only in dates.

A better planning strategy is to make detailed plans for the next week, rough plans for the next 3 months, and extremely crude plans beyond that. The benefit of  this decreasing resolution strategy is only the immediate tasks are planned in detail which is difficult to change, all the rest is flexible and open to changes.”

But the question is, how crude the plan is beyond the immediate future? Is it good enough give everyone, the customers and development team, an overall vision, and direction that this project is progressing towards? I am not absolutely against a PERT or Gantt diagram, because it gives you the complete picture of the project at the time. Yes, I agree that the structure of these diagrams will get changed and all. But that’s the best we get with the best of our knowledge at the time. I remember from an enterprise systems course I took at university, the 3 pillars of the course were “Goal driven strategies, strategy driven processes and process driven systems”. I guess it doesn’t matter what planning strategies we have in place, crude or charts. What’s important is, this planning is detailed/crude enough to reflects on the goal, vision of the business and ultimately software we are building. What do you think???

Console.Read(); // “Start reading damn it!”

I was never a good reader, never liked reading really. Guess that’s why I never got good at it. I tried really, I made several attempts on starting to read a few classics by Charles Dickens that I got given at college prize giving when I was leaving school back in 2001.

Thanks to Tim the other day, for what he said over yum-cha that inspired me; “If you want to be good at what you are doing, you’ll have to read.”

Agile development, Extreme Programming, SCRUM etc have been buzzing around the community for a while now, and I’ve decided to take a dive into it and see for myself. So here I am, picked up “Agile Principles, Patterns, and Practices in C#” by Martin C.Robert, Martin Micah and started reading it.

So, I’ll kick off a series on Agile Development as I progress through the book. I’ll blog about concepts/code examples from the book that I think are interesting / eye-opening, doubts that I have over what I read etc.

Here is something I read and reflects on me and work fairly well, unfortunately. Here I shamelessly quote from the book, it’s something I call;

Process Paradox

“Many of us have lived through the nightmare of a project with no practices to guide it. The lack of effective practices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules, growing budgets, and poor quality. Developers are disheartened by working ever-longer hours to produce ever-poorer software.”

“Once we have experienced such a fiasco, we become afraid of repeating the experience. Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these constraints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again and take away our fears.”

“But projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, we diagnose those errors and put in place even more constraints and artifacts in order to prevent those errors in the future. After many projects, we may find ourselves overloaded with a huge, cumbersome process that greatly impedes our ability to get projects done.”

 “A big, cumbersome process can create the very problems that it is designed to prevent. It can slow the team to the extent that schedules slip and budgets bloat. It can reduce the responsiveness of the team to the point of always creating the wrong product. Unfortunately, this leads many teams to believe that they don’t have enough process. So in a kind of runaway process inflation, they make their process ever larger.”

I’m not sure how many folks out there have worked / are working in a situation like described above, I’ve certainly experienced the first part this account. Unaccountable number of delayed dealines, countless number of working-till-next-morning-days, very unsatisfied customers/managers. Most importantly, loss of team morale, developers no longer have faith in the products they are building or simply don’t care…

So, what is the “silver bullet” to this process paradox problem (if you believe this problem does exist), agile development? I certainly hope to find out from this book as I progress through it. Watch this space… 😀