Thursday, 4 October 2012

Get 'Usability' into Use in your Software Design

'You do not need to be a mechanical engineer to drive your car or you do not need to have a hold on any automobile mechanics to use your car'. You just need to know how to operate the steering, clutch, break and gear, and of course other monitor and control interfaces. In short, you need to know ‘how to use your car’ and that is how ‘you want your car designed for you’. Software is no different.

Most of the times, the end-users of a software product are not the software developers. Even if the software developers are the end users of your product, they do not want to go through a big hassle to put the software into use. For example, if a Java developer is using any profiling tool from within his IDE, it makes his life easier if the product offers itself as an easy-to-use tool apart from being feature-rich and he doesn't really need to learn the technology behind profiling.

  • Usability is one of the major factors in the assessment of software. The complexity that you built into your software need not (and should not) reflect in its usage too.
As a software developer, you need to visualize how different end-users would be using your product (or would like to use your product) and design and develop accordingly. You may formally call it ‘User Centric Design or Development’ but in the end what matters is ‘the comfort and the ease with which the users understand and use your product’. In other words, if there are any possibilities where ‘design is driving the requirements’ (and you know what I mean), it is strongly suggested you pay close attention and strictly avoid such practices. Though ‘design-driven-requirements’ is not a common practice, it is sometimes likely to happen.

  • Usability is often confused with rich-looking interfaces (GUI) of the product. No, it’s not just that, though it is a part of it.
For example, while there are many Social-Networking sites out there, why are a few sites more popular than the others? Is it just the GUI? Why are some eCommerce sites more popular than others?
Giving out an example from the other side of software development - if you have developed a makefile, how would other developers in the team find it as ‘usable’? The makefile should able to tell you – ‘what are the different targets available and different options to use with those targets’. Also, things like, different module owners be able to build and deploy their own modules than building the whole software, every time they want to test something. The interface is not a GUI here.

  • 'User Documentation' is often considered as replacement to Usability. It's not correct.
 A detailed User Documentation is often cosidered as a replacement to address Usability requirement (example, how to navigate and how to recover from this error etc). Remember it is not just how the Documents talk to the user, but it is mainly about how the Product itself talks to the users. So, in brief, Documentation need to serve as a Complement and not a Replacement in using your product.

So, if you are designing your software, there are a few important things that you should ask yourself.

  • Who is going to use this software?
    • Business users? If so, who are the different types of Business users?
    • Software developers? If so, what would different categories of developers like to achieve from this product.
  • What they need to learn to put the software into use and maintain the same?
    • How they interface with the product? How easy is the interface to use the product?
    • What are the possible errors that users might hit while using the software? How does the software help the user understand and recover from these errors?
    • ...
Always remember that you are the constructor of the software but not the end user. The learning and complex configurations to deploy the software into production might look trivial and easier for you as you know the ins and outs of the software but NEVER ASSUME that the end user is expected to know all this information. So, take this additional care at the very beginning of your software analysis and design stages and avoid last minute surprises.

Verifying Questions

What is the importance given to the Usability when you design Software?

What is your process to invite the feedback on Usability with your Iterative development model?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Friday, 21 September 2012

Motivating Agile Teams

How to motivate my team towards Agile?

This is a very common question that most of the managers come across when an organization or a team is in the phase of rolling out Agile processes. I must say that there is no shortcut answer to this but I would take this stand - "Don't do anything special to motivate your team towards Agile".

Forget Agile for a while. Think of any product or service that you use, for personal use or professional use. You would probably love it for its value and not because of those eye-catching presentations or speeches on them. Of course, these marketing materials would get you there but ultimately the single reason why you like it or recommend it to others is for its VALUE. Now, the same applies to Agile. Though, end of the day, motivating the team is something that a manager has to address, he cannot do Sales and Marketing job to sell Agile to the team.

First off, before trying to motivate the team towards Agile, the manager needs to answer the question, "Am I motivated?". If the manager himself is not motivated, there is little that can be done about motivating the team.
There are a few basic things that a motivated manager can consider to encourage his team and come over the resistance of the team towards Agile. Bettering is not always about doing new things, but sometimes it is about not doing a few things.

Don’t make Scrum a status meeting:
--- Every individual would have this question inside them - What’s in it for me?.
--- Prove the value of scrum meetings by asking them right questions or providing them with valuable tips that would help them think better on their tasks and make them think that they are getting real value. Offer your help wherever you can.
--- Let status be a by-product but not the intention of the discussions.

Encourage Team Collaboration:
--- Prove the value of 'team collaboration' by encouraging healthy discussions and very soon they themselves find the value of Agile by seeing the team is contributing to their tasks and and they are contributing to the team.
--- Be participative and you would sell Agile by 'Doing' it. It is a different thing that the manager is hands-on or not. (There is always a difference of opinion on this and there are varied versions of  understanding a 'self-organizing team’. But, for now, it is good enough to say that it goes with the requirements of the project and every project is different.) Irrespective of a manager is hands-on or not, he can always play a catalyst role in that he would enable the team to get the things done.
--- If the scrum meetings and team collaborations are seen to be producing results, then you are there. On the other hand, if they see it as yet another meeting and yet another process, no 'artificial' stuff can motivate them.

Create a Complementing team, not a Competing team:
I often hear the idea of identifying and rewarding the ‘Best performer of the Sprint’. Remember the intention is not to create a Competing team but a Complementing team and there is a lot of difference between these two things. The idea is to create a motivating team towards a common goal. If you introduce these ultra-short-term rewards, what happens is individuals work for their own goals. Of course, good performance has to be rewarded but Scrums and Sprints are not the platform for this.

Don't let your intentions to motivate the team turn out to be actions to demotivate the team.

Verifying Question

If you are a manager - Are you making your efforts to motivate the team by showing the value of Agile in action?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Friday, 14 September 2012

Project Estimations & Planning in Agile

A valid question that is often raised is “Agile emphasizes that the Software projects are highly unpredictable in nature and Agile principles enable you handle the unpredictability better from Engineering point of view. But, from the Business point of view, how do you deal with the cost factor for Fixed Cost (FC) assignments?”. ‘How much does it cost me?’ is what the customer wants to know and ‘How many engineers do we need to allocate and for how long?’ is what your organization wants to know.
While there are a few good books available on this subject, let me try to put together a few things that I have understood from my experience.
Project Estimation and Planning, for most of the projects, is something which you cannot start without but cannot stick with. This is because there is always a cost factor associated with whatever you do and nobody would be ready to start the job without a plan - neither your organization, nor the customer. End of the day, it is not just an engineering problem but a business problem as well. Whether you like it or not, you need to come up with a project plan and it would give you an approximate effort estimation, if not accurate. Not only that, it also helps you understand different variables involved. But, at the end of the project, what remains true is the BEGIN and the END of the project. Everything else would turn out to be a filling-space just like a play-ground with defined boundaries(time and scope) where you make on-the-field decisions. Only question is how far the plan has changed from the original version to the end - and it depends on - How predictable the project is? How stable the requirements are?
Here is one approach that we used to follow for the fixed cost assignments:

- Provide an up-front project estimation based on the initial Requirements Analysis and the Project Scope. Provide a 10-15% buffer to accommodate for the requirements and tasks that were not identified before, but within the scope of the project. I am not saying this is the best but at least it worked for most of the assignments that we handled.
- This also included the Incremental & Iterative development plan.
- This required that we had to do a decent high-level analysis of the System to get as much a closer as possible to estimate the SIZE of the effort. For example, missing a requirement like ‘Providing User Registration Form’ in the application cannot be something that is backed up by saying that we are following Agile.
- As we go with the implementation and as requirements and design evolve, we had the flexibility with the SHAPE of the effort to alter the size and sequence of the iterations being Agile. This way, we used to maintain the balance between ‘Shooting in the Dark’ and ‘Shooting on the Dot’.
- Agile is not a replacement for capturing the Scope of the project and documenting the Assumptions and Risks. Irrespective of the format and name of the document, they need mention so that the Customer and the Service Provider can handle the things better on the estimations and the cost parts. You need to know whether you are going to implements Bananas or Oranges, where you think Bananas might change to Oranges and how it affects the Estimation and Plan.
- For the projects with highly unpredictable requirements or where the requirements are being developed (R & D in nature), T&M (Time and Material) or a combination of T&M and FC models are more apt. It all depends on how you work out with the customer on arriving at a consensus on what part of the project is predictable and what part of the project is unpredictable and needs R&D. It is not required that everything needs to be fit-in-one-size.

Apart from the approach that is outlined above, there are other approaches as suggested on this blog post (mentioned below) to handle the Project Estimations and Cost factors better. End of the day, it also depends on understanding the project variables and getting to know your customer to devise a model which suits you the best.
Refer to:

Verification Questions
Is your project management methodology addressing the Business and the Cost variables along with the Engineering variables?

Are you devising a right contracting method that is best suited for the project?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Friday, 7 September 2012

Deliver Value to the Customer

Just like you don't want to loose any customer getting in business to you, no customer would like to loose a service provider who creates value for their business. Customer retention is all about Delivering Value to the customer. Sometimes it is about understanding and delivering what the customer has asked for, and sometimes it is about proactively figuring out what the customer needs and delivering the same.
Let me try to put  this together with a small example from the top of my head.

One of our customers had a BPM tool and they were integrating their product with multiple third-party CRM, ALM and SCM tools to push the product in the market. We signed the contract with the customer to integrate their product with a CRM tool. Before the project came to us, the customer’s product had already been integrated with a leading SCM tool and we had to start from that source base.

The customer had no requirements for creating a reusable design with respect to supporting multiple integrations. Somehow, the customer had carried an opinion that writing mostly independent code for different integrations will keep them in a better place to manage the code better in that he would have the flexibility to change one integration without worrying about the other integrations. So, we too didn’t carry this discussion forward as it was not the right time considering the facts  - 1. Our team too didn’t know what were the variables of the equation and 2. There was no proper working code as a base for the discussion.
Here is how we approached this problem:
  • First, we focused on these variables:
    • How the existing integration was working?
    • How did we need to integrate the new tool?
  • For the new integration work, we implemented the necessary design principles like reusability, abstraction, error-handling and fail-safe and other things which were not respected very well in the previous integration that was already done. The new integration started working well and another tool was added to the product’s integration chest.
(As a side note - Because of the way the code was organized, a few of these things, with minor efforts from our side, came as a bonus for the existing integration. Not every single task can be billed to the customer if you are really worried about Customer Delight and Customer Retention.)
  • Following this, we had a discussion with the customer on the need for reusable and extensible design - now with some working code as a base, and it was the right time for the discussion. Technically also, we had understood what precisely were the design improvements to be made.
  • We worked out the details and implemented a reusable architecture for integrating more tools with the customer’s product.

From technical point of view, this example is about identifying and weighing the design decisions based on what-to-do, when-to-do and why-to-do as we discussed in the post - Business-Driven OR Fact-Driven Design. The rule of ‘Don’t change the working code’ didn’t apply here considering the ‘Return on Investment’ if it is overruled.
From business point of view, it is about identifying what the customer needs and Delivering Value to the customer. Again, this project is not one of those fortune-turner kind of projects that we handled, yet it carried some business importance and for a service based vendor, unless there is a very strong reason, every customer is as important as the other customers.
The design improvement added a lot of business value to the customer that they could add more tools to their product’s integration chest much faster. It is about reduced-cost and faster requirement-to-implementation cycles. The business value for us was that the customer started signing more contracts with us. End of the day. the question “What is in it for me?” has to answered for all the stakeholders. :)

Verification QuestionsDoes your team understand the customer's business enough to identify what the customer needs?

Do your team's decisions on the technical aspects, also consider the requirement of delivering business value to the customer?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Monday, 3 September 2012

Bootstrap Agile with Agile

If your organization is planning to roll out Agile processes, take it step by step starting from addressing the process issues in a priority manner just like you handle your customer projects. Let this knowledge and lessons flow from individual to individual and from team to team until at least the processes get stabilized. Let the teams be participative in the process improvements, and don’t try to force it hard, without reasoning, and don’t forget Agile principles here as well.
Collaborate People:
Collaborate with the team(s) in identifying and prioritizing the pain-points of the existing process. Suggested approach is to ask stakeholders from different roles and different experience levels to participate. This will bring the possible 360 degree view.

Be ‘specific’ about the problems and the proposed solutions. Don’t use text book statements. For example, ‘Follow iterative development model’ maybe too generic solution but identifying ‘What exactly would be the deliverables’ with an iteration's code drop and ‘How should we be following up with the customer’ will be specific.

Process the Feedback:
FeedbackWhat is that you implemented right?
What can be done better?

Let the lessons (good and bad) be shared across the iindividuals and the teams.

User Stories:
As a Developer, what is working for me and what is not working for me?
As a QA Engineer, I feel I need these requirements.
As a Project Manager, here are the issues that I would like to address.

Take out the Waste:

Take out Waste

The whole purpose of Agile is about minimizing the rework and waste and maximizing the productivity. So, implement only those principles of Agile that your team really needs. What worked for the other organizations and the teams may not be the same as what your team needs.

Example: If you don’t really need burn-down charts, don’t use them. If User Stories do not make any sense to your specific project, keep them aside. It is not just about spending time on things-of-no-use  but you are loosing time to be spent things-of-use.

Ask this simple question, “Is this method making my team do better or worse?”. Betterment is not always about doing new things. It maybe about not doing the things that-are-not-worth-doing i.e., taking out the waste.

To summarize, consider your process change also like a mini project, sticking to the basic Agile principles, processing the feedback with continuous attention with proper team collaboration. Things will fall in place in a matter of a few weeks. We may call this ‘Bootstrapping Agile with Agile’.

A process that is organically evolved would always carry more value than a process that is purely taught. As much as possible, try not to be biased by the name of the process but focus on the Goals that you need to achieve from the process that serves the interests of all the stakeholders.

Verifying Questions
What 'exactly' are the issues that you would like to solve with Agile?

What are the 'root causes' of these issues (not symptoms) so that you can plan implementing Agile from the roots? Remember it should not become yet another process.

"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"

Tuesday, 28 August 2012

"Is Everything Alright?” may not be Alright

Incremental deliveries are not just good enough. You should ensure that they are really adding up to the Constructive feedback in achieving your long-term goals, than just aiming for "Everything is Alright" with every incremental delivery.

When our team first started with the Iterative model of development, the information we used to exchange with the customer, used to be something like this:
  • Implemented ABC, XYZ, … features
  • Fixed the Bugs: XXXX, YYYY, ….
Okay, Alright(X) In the follow-up calls with the customer, we used to ask very generic questions like “Is Everything Alright?” OR “Are there any issues?” and we would be eager to hear from the customer side “Okay, everything is just perfect”. We didn’t use to pay enough attention to ‘How they were/should be testing the deliveries'. Often, we used to have a demo, but one cannot cover everything in a demo.

The customer came back much later in the project cycle reporting a few serious bugs which should have, ideally, been reported before. They cost us more considering the amount of refactoring and the other overhead (planning, prioritizing, additional testing etc.) required. This meant that the iterative development didn’t completely serve its purpose, though it made a few things better in handling the project internally.

It took us sometime before we realized a few facts:
  • ‘Incremental Deliveries Are Not Just Good Enough’ and we need to do everything right to ensure the customer would be testing those deliverables diligently in providing the Right feedback at the Right time.
  • Don’t even aim for “All is Well” reply from the customer in the beginning cycles of the project. It is not something to cheer upon. You should welcome Specific and Tangible feedback and Rework but don’t try to avoid it. Anyways you would be working on it later and you cannot escape from it.
  • Also, we became conscious about the addendum information that we had to deliver along with the incremental deliveries.
-Exact list of Testcases (Acceptance Tests); Scenarios that the customer can explore.
-What's Pending (Something for which you delivered a temporary or an incomplete solution) and ‘Known Failures’
-'In Process’ user documentation, if any
-Any other useful notes, that is not taught by your Agile coach but contextual.
  • Welcome those short-term hits for the long-term Quality goals.
  • Communicate ‘What has to be Tested’ along with ‘What is Added and Fixed’ because ‘the later a bug is caught, the costlier it is’.
  • ‘You test it Now’ is more practical than ‘You should have reported it before’.

When your requirements are highly unstable and volatile, use the incremental deliveries as artifacts to decide the direction you need to travel than just an instrument to validate what was done. This simple perception change brings in a lot of difference in your approach and methods you follow to receive the feedback. The same might be applicable, but to a lesser degree, in the scenarios where your requirements are fairly stable.

"Remember that the incremental deliveries are, in general, the production quality code drops and not miniature or prototype versions". So, even the validation has to be done on the similar lines. 

Sometimes, it is important to know ‘who would be testing your deliveries from the customer side’. It would be very useful getting in direct contact with them rather than getting the second-hand information from someone who is working with you on the requirements and estimations etc.. This will help process the information better and faster.

Verification QuesionsAre you ensuring that your incremental code drops being tested diligently from the customer side?

Are you talking to the right person from the customer side who is validating your deliveries?

Is the feedback you are receiving ‘Specific and Constructive’?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Wednesday, 22 August 2012

A few comments on Comments



You are not the owner of the code that you write. The owner is always the organization who you are working for, or the customer who you write the code for. So, please write proper Comments with your well-designed and beautifully-working source code, so that it helps you and other developers during and after the development cycle.


Let us talk something specific than general suggestions.

What does proper mean here?
Is it proper style and syntax?
Is it writing in proper place?
Or Is it writing proper text?

So, how about a few comments on Comments:

// Don’t hesitate writing a long Comment when it is necessary.
// Don’t sacrifice Comments for a beautifully-looking code.
// ‘Purpose’ of a Comment overrules ‘Beauty’ of code. 
// Don’t just explain the WHAT part but explain  the WHY part.
// Most of the times WHAT is more obvious with proper coding standards.


// Sleeps for 5000 ms

The above doesn’t serve any purpose. Rather, something similar to the following comment would serve the purpose right.

// (What) Allow time for the input processing. 
// (Why) From the testing performed, it usually takes around 2000-3000 ms in normal
// workload scenarios. So, using a 5000 ms delay to be on a safer side, considering
// significantly higher workloads and at the same time not slowing down the processing time.
// (Why for future) When we support xyz interface in future, we need to revisit this interval.
// We need more time delay to be allowed on xyz interface.
// So, the performance with this interface might be a bit compromised.

// Don’t add Comments which are very obvious.
// Comments and Coding Standards are Complements but NOT
// Replacements to one another.


// Copy all elements, field by field, from source to target.
src = getNextSrcElement();
target = geNextTargetElement();
// copy src name to target name =;
// copy src title to target title
target.title = src.title;
//Allowed bonus is 50% more in target per the following requirement
target.bonusLimit = 1.5 * src.bonusLimit;


// Necessary Comments are MUST than GOOD-TO-HAVE.
// Working-code is a subject of your Design and Coding skills and it is for your
// Compilers and Computers;
// Explaining-code is a subject of your Comments and Coding Standards and
// it is for us, the Human-beings.

Fixing an ‘Undeclared Variable’ error is a MUST situation that your compiler creates for you. Fixing an ‘Unexplained Code’ is a MUST situation that you need to create for yourself.

I don’t believe poor Comments have impact on Quality !!! ??? They are just plain text.
Man with a Question
Yes, they may not have immediate or direct impact and that’s probably why some developers safely put them on the back burner. But in the long run, here are some of the bonus items offered by an ‘unexplained’ or ‘improperly explained’ code. :)
-- Removing/Modifying a line of code which shouldn’t have been and thus attracting regressions.
-- Longer cycles to understand the code as part of code reviews, bug fixing, code extensions etc..
--- ---------------------------------------------------------------------------------------------------------------------------

So, the inference is:
// Our goal is not 'writing Comments' but it is 'writing some useful information, which cannot be conveyed just though the executable code, in the form of Comments'.
// Write 'Necessary and Sufficient' Comments maintaining the balance between Readability and Maintainability of the code.
// Once you have written the Comments, read them 'from the future' point of view and 'from the eyes of the other developers' to ensure the Comments are serving their purpose right. If you want to understand ‘why’, try reading your own code (without comments) that you have written a few weeks back.

Verifying Questions
Does your team understand what 'proper' Comments mean?

Does your team understand the role of proper Comments in the long run maintenance of the code?

"Let us not forget the basics even when we are doing the amazing things."

"Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net"

Tuesday, 21 August 2012

Business-Driven OR Fact-Driven Design

It’s not always the technical reasons that drive the design decisions. More often, they are business based too. 'What design decision are you making' should also factor in 'When are you making the decision' and 'Why are you making the decision'. This is one of the areas where an experienced project manager or an architect can guide their technical teams in making those right decisions - means just right for the time and the context. This is what we can call as a Business-Driven-Design or a Fact-Driven-Design.

There are two extremes as far as our approach to design is concerned:

Piecemeal Approach - Not paying enough attention to design and writing code on a piecemeal basis. It can be due to lack of necessary technical expertise or due to high misinterpretation of the Lean Development concept and thus making it more leaner than it has to be.
[This leads to highly unmanageable and poor quality code and will have impact during and after the development cycle]

Best Design Approach - Trying to apply everything you learnt about 'Software Design' and 'Design Patterns'. Well, I was not an exception here. :)
[Possible under all imaginary and ideal conditions like - you have unlimited time OR you do everything right to the perfection the very first time. Practically, it is never possible.]

Common sense and business sense play their roles in coming up with a design that is ‘necessary and sufficient’ with reasonable trade-offs made. In other words, it is about the art of looking beyond your code. 'Trying for a right design at a wrong time or for a wrong reason may turn out to be more dangerous than a poor design.
What When Why

Invest in better design only if it is necessary and only when it satisfies the simple rule of ‘Return on Investment (RoI)’ .

For example, assume you are developing a tool for some kind of Tax Processing requirement, supporting two different Tax Implementations, say Sales Tax and Corporate Tax.
-- If you are sure that no other tax types will be added in future, do not try to get the best design in terms of abstractions and reusability. It is not necessary though technically right. Handle them with simple if-else logic wherever you can, after having just-sufficient abstractions and reusable code implemented.
-- On the other hand, if you know there are going to be multiple other tax types supported, handle them better in terms of design. It is technically right and necessary as well. Even, this helps you make right decisions on all other connected things like whether to use a radio button or a drop-down box for selecting the Tax type on the front-end.

  • Temporary trade-off
For example, if you are about to make a code drop and you have noticed a 'non-trivial but useful' design change to be made, do not handle this in haste. Your decision might be right, but not the time. Rather, push this to the next iteration, probably as a first things to do.

  • Permanent trade-off
For example, if you are product based and your eye has caught a design improvement to be made right before a release, let the technical guy inside you sleep for some more time. You are too late, though you are right. The best design 'now' is the design that is already working. This is where ‘Don’t change working code’ makes sense.
[If the impact is significant but not severe (like a typical performance issue), it can be handled in a follow-up release.]

It is mixed with what-to-do and when-to-do.

-- Why do I need to design this way or that way?
-- What is the benefit for me or the impact on me during the development cycle? (Well, it is not about your performance appraisal and pay hike. :) )
-- What is the value/impact for the customer after the delivery?

If you don’t have enough time or enough data and you have to choose between 'better design' and ‘working code’, it makes perfect sense to prefer the latter. Spend the time you have for doing better things like - testing your code properly and fixing any potential bugs.

Questions to AskAre you making the right design decision (to-do or not-to-do) at the right time?

Are you considering the 'value proposition' in making the design decisions?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Tuesday, 14 August 2012

Bend the Rules(safely) to Win the Game

When your team is on to executing a project, there is always a task-breakdown (Milestones->Features->Tasks etc.,) exercise done. The way you do the task decomposition is, most of the times, influenced by how you/your team had done it in the previous projects. But, as your project goes on, there might be some feedback - be it internal or external - that helps you revisit the effectiveness of your task-breakdown. This might enable you identify the opportunities to execute the project better and faster, yet respecting the sustained development. 

This is some lesson which our teams learnt by practice when the things forced us to do so. Here is an example of how we learnt this hard lesson:

Quick background of the project...
  • The project was about migrating a System-level application, from one hardware architecture and OS to another hardware architecture and multiple other OS platforms. 
  • This was the project which had the potential to change the fortune of our company (in fact, it did) and could help us move to a “Next” level in the business. Thus it carried a greater business importance.

We were thinking, we were doing just right...
  • The major portion of the “Task Breakdown” in our project plan was done based on the “Functional” features of the product. “Task Distribution” among the team was done based on this. 
  • We were doing incremental code deliveries every 2 weeks or so. We were almost 30% into the project timeline (excluding the time we spent for the initial Inception and Elaboration activities in the first few weeks). The line items on the MS project planner were looking GREEN. :)

The customer’s feedback that made us rethink our approach...
FeedbackThings were looking very bright and we were thinking that we were on the right track, until we got this message from the customer side on a fine day.

"The customer, in his feedback, politely screamed that they were not so happy with the project progress per the validation metrics they were using". 
  • The customer stated that, as per the Automated testsuite that they were using for measuring the project progress, hardly 8-10% of the testcases were working whereas we were almost 30% into the project's timeline.
  • The customer’s concern, in this case, was not about the Quality but the question raised was whether our team would be able to complete the project on time.
  • It was HIGH time that we had to win the customer back in the game. Definitely, and without choice, we had to do something about it.

Then, how did we react...
Run Around ClockAn immediate jerk reaction would have been that the project manager asking the team - ‘Let us slog it out, and bridge the gap, come what may and I promise you late-night dinners:)’. This would have made everyone run around the clock. But our team, guided well by our project manager, did something different. What we analyzed was the fact that we could do the work breakdown and distribution in a different way.

  • There was considerable overlapping(duplication) of efforts with individuals owning the tasks based on “Functional” Features. This meant that more than one engineer were working on migrating the same source code files at the same time.
Task Breakdown
  • The corrective step taken was to break and own the tasks based on the 'Sourcecode files' to enable us perform bulk modifications in an iteration. We had enough technical details for doing this and I am not mentioning them here.

  • Now, our iterations became slightly longer because we needed to have enough room to test the bulk code modifications before delivering the code drops. We explained this to the customer and got their acceptance as well. Of course, “All conditions Applied” works neither for the customer nor for the service provider. There needs to be reasonable trade-offs made.

With this approach, we bridged the gap that we had with respect to the project progress and also continued the same approach for the rest of the project duration.

What is meant to be conveyed through this example?
  • Breakdown-into-Tasks doesn’t have any standard formula. As long as your approach to this is logical and your team knows how to validate, it is right-for-the-project and right-for-the-context.
  • Practically, you cannot get all your practices defined to the perfection when a project starts. You just cannot get started with too many variables in hand. Also, the demands of the project are always different at different times.
  • It is about your continuous attention to the details and how do you constantly tune your approach to what-is-more-apt. Probably this is what “Responding to Change” was meant for this specific instance explained.
  • On top of all, if you are a project manager, involve your team in making important decisions that would have impact on both “Customer Satisfaction” and “Team Satisfaction”. In this case, if the project manager had a made a decision to “slog it out”, he could have still won the customer but at the cost of the team satisfaction.

Is your team's task-breakdown the best during all phases of your project? Is there anything that can be done better?

If you are a project manager: Are you involving your team in making those important decisions that would have impact on sustained development?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Friday, 10 August 2012

Is Agile limited to Development projects?

Can we practice Agile in a maintenance project?
Can we follow Agile in executing a migration project?
Can we use Agile in …?
Is Agile limited to only development projects?

What drives us to adapt to a new process or alter an existing process? It is always this golden objective - Quality. Different projects carry different Quality criteria. Before trying to find an answer for “How do we deliver Quality in this project?”, we need to answer “What does Quality mean for this project?”

Let me try to illustrate this with an example of how we implemented Agile in a Production Support project.

*A quick background of the project:
  • The project was about handling the business-critical Production Support for a telecom client. This was handled offshore completely.
  • The customer’s business was tied up with different Service Partners to provide end-to-end service to their customers. Taking this to technical terminology, it was all integrated on an SOA based architecture.
  • Often there were service failures due to various Technical and Operational reasons and our job was to analyze those failures and handle them offline.

ID-10091674*So, what was Quality meant for this project?
  • Reliability - As we worked on the production issues, it was a MUST that our solutions were highly Reliable.
  • Better and Faster - It was DESIRED that we provide continuously better and faster solutions, considering the huge customer-base of our customer.
  • Timely & Consistent communication with the business users - We had to work with the onsite team, working on the other side of the globe. So, our communication with them had to be -
    • Timely - Delays, due to timezone differences, should be minimized so that end-customer concerns are addressed at the soonest. Not a typical requirement in Development projects.
    • Consistent - Our communication with the onsite team should always reflect that either we know something or don't know something as a Team but not as Individuals. It is highly DESIRED from business point of view.
  • Continuous Learning of the System: It was a complex system and so it was DESIRED that we learn the system better and better as we go dealing with various issues.
  • Customer satisfaction through End-Customer satisfaction: "Our customer will be happy, if their customers are happy". This is the simple business rule that we always respected.

*So, how did we implement Agile here?

The daily Scrum meetings played a major role here and this is how we tuned our Scrum approach in dealing the issues reported by the end-customers.
  • What is New (Either we didn’t handle this before or this is slightly different from what we handled before)?
Can we handle this ourselves? If so, who is the best person to handle or help? Or, do we need to approach the onsite team? (Providing ‘Reliable’ solutions)
This is towards the “Reliability” criteria.
  • Are there any Bulk (High in number) and Repeated (being seen more often) issues?
This is towards identifying the need for building new tools or modifying the existing tools (Automated or Semi-Automated) to meet “Better and Faster” criteria.
  • Any escalations?
Business SLAs take priority over having a perfect solution (‘End-Customer satisfaction’).

-- Timely communication with the onsite team and continuous learning of the customer’s business were the by-products of these discussions.

-- It also helped us address the Single-Point-Of-Failures (SPOF here is Knowledge being confined to individuals). SPOF would, in general, have more impact in a Production environment than in a Development environment.

-- We never discussed the issues that were routine and they were far off the Scrum meetings. Our meetings intended to be meaningful and action-oriented. We didn’t make them daily status meetings. Our team was enabled to take care of the routine issues by themselves.

What is meant to be conveyed through this example?

-- Challenges are different for different projects. Some projects would be more about ‘What to Implement’  whereas some projects would be more about ‘How to Implement’?

-- Our project was more about ‘What to Implement’ than 'How to Implement’. I must say that technologically it was not so challenging but we were constantly identifying and implementing the tools(Java/J2EE and PL/SQL based - just to add) that create value for the customer's business. So, it was more of a business challenge.

-- There was no concept of continuous delivery, iterative development, early feedback etc. in this particular customer engagement. From a different sense, our solutions were reaching to the customer on a daily basis (unlike in a typical Development project).

-- To state the fact, it took us some time to figure out what exactly were the expectations and the Quality criteria. Every project would see this phase, particularly when your team is handling a new type of project. Some conscious experiments and trial-and-errors are required to get on to the right track.

The subtle message that is intended to be conveyed is - ‘Work on identifying your Quality goals and customize your practices to achieve those goals’.

What are the Quality objectives of your project? How is it different from the other projects that you executed?
How can you apply the tools(practices) available for the job-in-hand? What works for you, and what does not work for you?

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)

Monday, 6 August 2012

Process is a way, Practice is the key

“Name of the process cannot make any magic by itself. The set of yet another BIG terminology in the process documents is not just good enough to reach your Quality goals. It’s all about your practices and how you tune them to suit the long-term(final project deliverables), short-term(iteration or sprint) and immediate(problem-in-hand) needs of your team.”

Here are some practices that can be promoted and encouraged along with the so called process improvements.

Ownership & Contribution
“Everyone cannot be good at everything. If someone is good at thinking of a better design, someone else will be very good at writing some complex string parsing logic. Respect Integration of Skills along with Integration of Tasks.”

  • Every individual takes the ownership of delivering the tasks assigned to him.
  • Everyone has the right to seek help from others when needed or offer help to others as desired.

Your Boss need NOT be right all the times
  • Okay, it’s not that “Boss is Never Right” :)
  • Create an environment where healthy debates over project issues/technical options take place with Quality of the project as a common goal.
  • Manager contributes but doesn’t impose his ideas on the execution though he solves the conflicts. Team’s agreement is always respected.

Meaingful Meetings
Break the rules. 'Getting the job done' is the ultimate goal.

(x)Scrum is not more than 15 minutes: Not correct.
  • As long as the team is discussing something useful that adds to the Quality, a few minutes extra is worth it. Remember, Agile is basically about minimizing the rework and waste and scrum is a very good platform for this. There is no point being too strict on this time.
  • Remember that a considerable part of a typical software project time/cost is spent in rework and bug-fixing if the teams are not properly collaborated. Do the right thing at the right time.

(x)Everyone should stand in the Scrum: Not necessary.
It’s okay as long as everyone participates actively.

(x)Technical issues not to be discussed: Misinterpretation.
Technical issues are always on the top for discussions. Yes, you are right. Only those strategy and planning meetings cannot create working code.
Discuss things like “HashMap Vs HashTable” that caused a bug in your code; the interesting thing that you have come across about some String parsing logic that everyone should make a rule to follow; Revisit exception handling in the code developed so far with a hint from some bug encountered; Show that piece of code if it helps the team; Anything that is a parameter for the top-most goal - Quality.

The guideline is “your learning” should add to the “quality of the team” and not just the “quality of the individual”. There is no point in the same mistakes are getting repeated with different individuals at different times.

(x)One cannot speak for more than 3 minutes: What purpose does it serve?
If someone has something important to update or share, let him take the time he wants. The intention is to serve the purpose right. Don’t use ‘Stop-Clock’ methods. Maybe the issue he is encountering might lead to uncovering a major product bug which is worth fixing now than being reported by the customer.

Wisdom of the Group
“Okay, YOU are good, but WE are better together”. Different individuals bring in different insights. It’s not that everyone is to be on every task though.

Don’t wait for the scheduled meetings
If there is some potential bug or logic flaw that you have noticed, stand-up and speak it loud. Often, informal meetings are far more effective than formal and scheduled meetings. That is because informal/at-the-desk meetings are mostly about something “specific” and thus very much focused.

Knowledge Sharing
"Share the knowledge and that’s how you got it. Scrums are generally a good platform for this, though not limited to."

  • Create a platform where knowledge sharing happens on a continuous basis, without saying and without planning.
  • Knowledge sharing is not just those PPT presentations.

Set aside the rules, Do-What-Is-Needed
  • If there is an erroneous code that has to be corrected, do that NOW before you build something more on that erroneous code. Otherwise you are consciously adding more bugs to be fixed later.
  • Relax your sprint backlog spreadsheet before the flaw creeps in other places. Communicate with the other stakeholders accordingly as needed.

Be a good listener, pay attention to what others speak
Applies to everyone in the team. No more explanation is required. Don't forget that 'good learning skills are part of good communication skills'.

We need to understand the fact that none of these principles are meant to deal with the incompetency of the team members. It is all about complementing the individual efforts to get the job done more effectively as a team. It’s about how you can demonstrate 1+1 = 3 (Complementing rule) than 1+1 = 1 (Overhead rule).

As one can depict from the above, these guidelines are not a matter of documentation but a matter of practice. Things that are understood well can always be implemented well.
Is your team working as a Team?
Yes, you read it right.
Is your team working as a Team?
(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)